GNU bug report logs - #29575
25.3; Secret Service API treats labels as unique

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Allen Li <vianchielfaura <at> gmail.com>
Cc: 29575 <at> debbugs.gnu.org
Subject: bug#29575: 25.3; Secret Service API treats labels as unique
Date: Mon, 11 Dec 2017 14:02:34 +0100

Allen Li <vianchielfaura <at> 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.

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.