[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29575: 25.3; Secret Service API treats labels as unique
From: |
Allen Li |
Subject: |
bug#29575: 25.3; Secret Service API treats labels as unique |
Date: |
Mon, 21 May 2018 00:51:29 -0700 |
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.