Missing API for changing secret of a dbus collection

[haecker-felix]

Unlike portal::Keyring, we currently have no (direct) way to change the password of a dbus::Collection. I think the main problem here is that changing a collection password isn't part of the secret-service dbus specification.

Seahorse / gnome keyring work around this and have something custom implemented (org.gnome.keyring.InternalUnsupportedGuiltRiddenInterface).

A possible workaround I can see at the moment would be to load the collection as a keyring file via portal::Keyring and change the password there - although I'm not sure how many side effects it would have to fiddle with the keyring file directly instead of using the intended oo7/secret-service api.

I wonder if this is something we can fix on oo7 side, or if we need an updated/extended secret-service dbus specification.

[bilelmoussaoui]

Unlike portal::Keyring, we currently have no (direct) way to change the password of a dbus::Collection. I think the main problem here is that changing a collection password isn't part of the secret-service dbus specification.

At least gnome-keyring's current implementation doesn't allow any collections other than login/session. The former is unlocked when you log-in and the later stays alive for the duration of the session. Sadly you can't create new ones :p hopefully something we can fix with the new server implementation.

Seahorse / gnome keyring work around this and have something custom implemented (org.gnome.keyring.InternalUnsupportedGuiltRiddenInterface).

We would have to implement that interface for server side. But I would not expose that as an API at all.

A possible workaround I can see at the moment would be to load the collection as a keyring file via portal::Keyring and change the password there - although I'm not sure how many side effects it would have to fiddle with the keyring file directly instead of using the intended oo7/secret-service api.

I don't think there should be any effect imho. but maybe @ueno can think of something that might break (other than auto-unlocking when you login)

I wonder if this is something we can fix on oo7 side, or if we need an updated/extended secret-service dbus specification.

Asked differently, why you would want to change the collection's unlock password

[haecker-felix]

At least gnome-keyring's current implementation doesn't allow any collections other than login/session

Huh. I can add new collections from both Seahorse and KeyRack finely. How does this work if it is not implemented in g-k-d at all? Or do you mean something else?

Asked differently, why you would want to change the collection's unlock password

Own keyrings/collections which you created from Seahorse / KeyRack. You're only able to set the password once when you create the collection, afterwards there's no way of changing the password (at least using Key Rack, Seahorse has the ominous guilt ridden interface).

I don't think there should be any effect imho

I can give it a try. I was a tad worried when g-k-d has the file opened / writes something to it, and I access it at the same time with oo7 to change the password

other than auto-unlocking when you login

From KeyRack side I only would allow to change the password for custom collections either way, the login collection password should stay in sync with the user password so that the auto unlock works.

[haecker-felix]

I don't think there should be any effect imho

For the record, I successfully avoided having to fiddle with files at all by using the org.gnome.keyring.InternalUnsupportedGuiltRiddenInterface interface in Key Rack. This makes it possible to change keyring passwords the same way as Seahorse does.

See https://gitlab.gnome.org/sophie-h/key-rack/-/merge_requests/23

This works, but perhaps oo7 can provide a better API for this in the future, especially if it becomes a secret service/gnome keying server.

[bilelmoussaoui]

I don't think landing that was great, because it is not an interface I think we should keep in the future and it is tied to GNOME Keyring specifically.