Secret Service: UI to manage alias mappings

[michaelk83]

Summary

From https://github.com/keepassxreboot/keepassxc/discussions/8475#discussioncomment-3659989:

Currently, KeePassXC sets the "default" alias to the currently active database tab, as long as it has a group exposed to Secret Service. This should be managed through a dedicated settings UI, along with other alias mappings.

Context

As it is, if there are two databases with exposed groups, switching between them to do something completely unrelated to Sercret Service can cause client apps to access the wrong database.

Furthermore, the spec suggests there should be an interface to manage alias mappings in general:

For applications like password managers it can be useful to allow the user to configure which collection is associated with which well known alias.

The full mapping should probably go to application settings, and either file path or UUID can be used to identify the database. Maybe both: file path for loading, UUID to make sure it's the correct database.

In addition, when the user exposes a group to Secret Service, they should be able to specify an alias for the database (or leave it blank). If there is no "default" alias defined yet, that should be preselected.

May be related to https://github.com/keepassxreboot/keepassxc/issues/7574#issuecomment-1120686985 (plus the two comments above it for context).

[hpfr]

Permalink to fragment: https://github.com/keepassxreboot/keepassxc/blob/422fd9125534fc26adf85d6bd31dd868a19f910d/src/fdosecrets/objects/Service.cpp#L81-L82

This looks like a solid proposal. Verifying a database path with the UUID makes sense.

Related discussion took place at https://github.com/keepassxreboot/keepassxc/issues/8611#issuecomment-1291272429.

I think it makes very little sense to have the default alias switch between different databases, since client apps expect to find their passwords where they stored them. If the alias is switched to a different database, the passwords will not be found.

I don’t think a properly implemented client has this issue. As described in Chapter 5. Lookup Attributes, the Service interface provides a method to search all collections. Clients can use the Collection interface to search a single collection, so I guess a poorly implemented client could force the default collection, but that seems like something clients should fix. Anyway, that’s not that important. I agree we should be able to manually configure aliases to avoid the UI changing them on the fly. Even if alias configuration is not necessary for reading, updating, and deleting items, it is for creating.

Another option is have only the host-specific FDO database, and sync to the other DB or host via KeeShare.

Ah, I haven’t looked into KeeShare before. If I understand this correctly, I could export the root group from my main cross-host database and import it as a subgroup in my host-specific databases for shared secrets like browser passwords. I would also have to export the FDO subgroup from the main cross-host database as its own share so I could import it into my host-specific databases’ FDO subgroup, since currently only one group can be exposed to the secret service[^1] and I don’t want to expose my entire cross-host database over the secret service.

[^1]: The one-group-per-database FDO limitation could probably be reevaluated at some point as well, but it’s not a major issue.

[michaelk83]

I think it makes very little sense to have the default alias switch between different databases, since client apps expect to find their passwords where they stored them. If the alias is switched to a different database, the passwords will not be found.

I don’t think a properly implemented client has this issue. ...

Ah yes. When I wrote that bit, it escaped my mind that lookup is location-agnostic when done through the Service.SearchItems() method (but not by other means). That indeed would be up to the client.

However, as you mention, creation of secrets is not location-agnostic. Updating and deletion are semi-agnostic: you do need to know the correct location, but you can look it up with Service.SearchItems().

I haven’t looked into KeeShare before.

https://keepassxc.org/docs/KeePassXC_UserGuide.html#_database_sharing_with_keeshare There are likely different configurations that could be used, depending on what you need to accomplish.

[hpfr]

I was indeed able to get an adequate setup with KeeShare, but it’s kind of janky. Also, you can’t secure KeeShare containers with 2FA, unfortunately. That’s all irrelevant to this issue, but figured I should follow up for future searchers.

[siddhpant]

bump