Subject: bug#29575: 25.3; Secret Service API treats labels as unique

From: Michael Albinus <[email-masked]>
Date: Tue, 12 Dec 2017 09:35:52 +0100

Allen Li <[email-masked]> writes:

Hi Allen,

> Yes, I plan on implementing a personal password manager using the API.

Is it a standalone program, or an Emacs package? In the latter case I
recommend to try auth-sources.el. It is the default "password manager"
in Emacs. The Secret Service API is integrated as one backend, although
there's room for improvement.

>> Well, inside the org.freedesktop.Secret.{Service,Collection,Item}
>> interfaces, an item is identified by an object path. We could extend our
>> interface to allow both label and object path as item, and to throw away
>> the "unique label rule" inside collections.
>
> That sounds like a better starting idea.  One problem that comes to
> mind is that the object path could be a valid label value, I think.

That's possible, yes. But I doubt it will happen in reality. At least in
Emacs we could check, that a label doesn't look like an object path, and
suppress such items for being considered.

> I don’t think the specification places any guarantees on the object
> path either, e.g. if another program modifies an Item, does that
> change the object path from under us?  That would cause race bugs.

secrets.el registers for several signals already, like
"org.freedesktop.DBus.NameOwnerChanged",
"org.freedesktop.Secret.Service.CollectionCreated" and
"org.freedesktop.Secret.Service.CollectionDeleted".

We could also register for the signals
"org.freedesktop.Secret.Collection.ItemCreated",
"org.freedesktop.Secret.Collection.ItemDeleted" and
"org.freedesktop.Secret.Collection.ItemChanged" in order to be notified
about such changes.

I don't know whether I have sufficient time to work on secrets.el next
weeks. Would you be interested in providing respective patches for secrets.el?

Best regards, Michael.