-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secret Service: UI to manage alias mappings #8479
Comments
Permalink to fragment: keepassxc/src/fdosecrets/objects/Service.cpp Lines 81 to 82 in 422fd91
This looks like a solid proposal. Verifying a database path with the UUID makes sense. Related discussion took place at #8611 (comment).
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.
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 service1 and I don’t want to expose my entire cross-host database over the secret service. Footnotes
|
Ah yes. When I wrote that bit, it escaped my mind that lookup is location-agnostic when done through the 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
https://keepassxc.org/docs/KeePassXC_UserGuide.html#_database_sharing_with_keeshare |
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. |
bump |
Summary
From #8475 (comment):
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:
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 #7574 (comment) (plus the two comments above it for context).
The text was updated successfully, but these errors were encountered: