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

[Allen Li]

On Mon, Dec 11, 2017 at 5:02 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> Allen Li <vianchielfaura@gmail.com> writes:
>
> Hi Allen,
>
>> The Secret Service API [1] treats labels as unique keys for each
>> secret item in a collection.  However, labels are not required to be
>> unique in a collection [2], the attribute key/value pairs are.
>>
>> It is perfectly valid to have multiple secrets with the same label, in
>> which case Emacs's Secret Service API is not able to retrieve all but
>> the most recently created (?) secret.
>>
>> This can be demonstrated by creating two such secrets using the
>> secret-tool utility:
>>
>> secret-tool store --label=Test1 id foo
>> secret-tool store --label=Test1 id bar
>>
>> You can see how the attributes uniquely identify secrets:
>>
>> secret-tool store --label=Test2 id foo  # This overwrites the first secret.
>
> First of all: do you have a use case in mind for this? Whether we'll
> extend the Secret Service API depends on the real need.

Yes, I plan on implementing a personal password manager using the API.
I am not planning on a design that requires duplicate labels, but I
hesitated on starting my project because I predict implementing other
tools that interact with the same underlying keyring service that use
duplicate labels for implementation simplicity or other reasons.

>> Implementation idea: Use attribute plists instead of label strings to
>> uniquely identify secret items.
>
> 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.  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.

>
>> This would require creating a new copy of the API to preserve backward
>> compatibility.
>
> The change proposed above would be backward compatible.
>
> Best regards, Michael.