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

[Allen Li <darkfeline@felesatra.moe>]

Thanks.  It doesn't look like there is a way to get the object path by
searching attributes?  That means there's no way to get the object path for
a secret added from a cooperating application (that may not have a unique
label).  secrets-search-items returns labels.  Ideally there would be a
variant of secrets-search-items that returned object paths.

Also, the docstring for secrets-create-items now has this line which I
think is misleading:

The label ITEM must not be unique in COLLECTION.

Should it be:

The label ITEM does not have to be unique in COLLECTION.
On Tue, May 15, 2018 at 5:56 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Michael Albinus <michael.albinus@gmx.de> writes:

> Hi Allen,

> >>> 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.

> Finally, I found the time to implement this. `secrets-create-item' does
> allow labels now which exist already in a collection. `secrets-item-path',
> `secrets-get-secret', `secrets-get-attributes', 'secrets-get-attribute'
> and `secrets-delete-item' allow also object paths as argument.

> Pushed to the master branch. Could you pls check whether this fits your
needs?

> Best regards, Michael.