v2.0.0-rc.2: Improved performance and v1 compatibility
·
223 commits
to master
since this release
Here's how the secret-service credential store works now:
- We always use service-level search. So no options are needed to turn it on or off.
- We always add a
target
attribute when creating new items. - We always just search for the service and user. So we find both v1-style entries (with no target attribute) and v2-style entries (with the target attribute). We filter the found results so they are either v1-style entries (which are assumed to have a matching target) or v2-style entries with a matching target.
- If we ever get multiple hits on a search, we return an ambiguous error.
set-password
works by doingget-password
and then, if it finds a unique item, setting the password on that item. If there is no matching item, it creates one in a collection labeled by the target (creating that collection if necessary). Note that thedefault
target is the only collection found by alias; all other collections are found by label.
This seems to provide the best of all worlds: v1 and v2 are now completely compatible, and we can create collections if the client uses a non-default target. (Note that v1 never created collections, and it always used the target name as an alias, so in effect it was completely restricted to using the default collection.)
If (due to 3rd party items) an ambiguity is found, there are platform-specific entries for getting all the passwords or deleting all the matching items.