Loading secrets generated using python-keyring in different applications
- Dominant language
- Python
- Stars
- 1.5k
- Forks
- 196
- PR merge metrics
- No merged PRs in 30d
Description
I want to load the secrets from a (gnome-)keyring, which were created using
python-keyring, in my editor. The editor has support for loading secrets
from the keyring. However, I had a problem finding the secrets for a
specific hostname. The reason for problem is that my editor iterates over
all the items in the Login keyring until it finds one that has an attribute
called ["host" ](https://github.com/emacs-mirror/emacs/blob/048b1aaec8d5cd4ce6e6a5a9b8091608d0af81a6/lisp/auth-source.el#L2392-L2403) matching the desired hostname. Since python-keyring uses the
attribue "service", no match is returned in my editor.
**Now comes the question(s)**:
Is there any reason why "service" was [chosen](https://github.com/jaraco/keyring/commit/d196463f4cdca822237d911ef3dee20c517a13f9#diff-5fbc40a8bddaf9eee1d019d523a515dfca83d6be219a6ddc32305d6b265bfb3fR190) as
the attributename of the secrets stored in the Login keyring? I guess that
the [chosen attribute names](https://github.com/jaraco/keyring/blob/258fd7d2bb200a6cf2dc7a0ea769b111d1885857/keyring/backends/SecretService.py#L89-#91) are not standardized, right?
This is the item in my keyring, created using the python-keyring library.
```
`-[-] Password for ’thomas.hisch’ on ’hostname’
|- password: ************* [Show password]
|- application: Python keyring library
|- service: hostname
|- username: thomas.hisch
`- xdg:schema: org.freedesktop.Secret.Generic
```
Is there also a reason why `org.freedesktop.Secret.Generic` was chosen as the
schema instead of creating a new schema? I'm asking because using a
different schema would allow to add support for it in my editor.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading keyring/backends/SecretService.py and the linked Emacs auth-source.el code, then compare the attribute and schema choices described in the issue. The issue does not define a specific compatibility change; done would require an agreed direction for interoperability and corresponding implementation or documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100