Replies: 4 comments 3 replies
-
Well you are using a raw api with keyring and not a client application. Part of the process of using an application that speaks Secret Service is to enroll your credentials with that service and store that enrollment information for later retrieval. The name of the database is not relevant in this scenario. When you do raw calls then it becomes relevant. |
Beta Was this translation helpful? Give feedback.
-
The Secret Service API spec does not have a concept of "service name". It does have a concept of collections, which is a way to group secrets together. It seems that Regardless, when a client application needs to store secrets in Secret Service, it has two options:
When a client application needs to look up secrets ( With KeePassXC, there's an additional complication: if the relevant database is locked, it's not able to perform the search: #4443 (comment) . Though in recent versions it should ask you to unlock the database in that case. Currently, KeePassXC sets the "default" alias to the currently active database tab, as long as it has a group exposed to Secret Service. You can check which paths are available by running the command Some relevant links if you want to read deeper: |
Beta Was this translation helpful? Give feedback.
-
@droidmonkey , maybe that should be a setting somewhere? 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:
|
Beta Was this translation helpful? Give feedback.
-
Excuse the delay and thank you very much for the kind and insightful explanations @droidmonkey @michaelk83! I will take a closer look at the Thank you for your help! |
Beta Was this translation helpful? Give feedback.
-
Summary
I'm currently playing around with https://github.com/99designs/keyring to see if it works with KeePassXC's secret service. It sort of seems to do, in a way. The first thing that I noticed was that
keyring
requires specifying aServiceName
, which it then uses to query dbus:In KeePassXC the
collection
seems to be the actual database name. I don't know too much about dbus protocols, but to me it seems that the client querying a secret should not have to know how the KeePassXC database is named in order to query it.I don't know if this makes sense, but it seems that if KeePassXC maps the
/secrets/collections/<NAME>
to the database name, then KeePassXC should also allow setting a database as default collection, so that no matter what a dbus client might query, it would end up requesting the default database. Just an idea, again, I'm not too much into the dbus internals, so I don't know whether this makes sense or whether it would break other things.Beta Was this translation helpful? Give feedback.
All reactions