-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
Support for creation of key-pairs #462
Comments
Hey Dany. Definitely open to improvements, and as we've seen with the introduction of To start, what is it that's special about public/private keypairs? What features would you expect from an interface supporting keypairs? What would prevent a library from building on top of keyring to store/retrieve a key pair using the |
@jaraco - great questions, I think that the last one stresses an important point, I've looked at other supported backends (namely, SecretService, KWallet, Win CredLocker), to get a better feel as to if any of them have a dedicated key pair primitive; To that end, I think you led me to a better option - I can either create an external backend that uses One of the above will fit well with my end goal - so I don't think there's a clear advantage to have such support baked in to the library itself. Appreciate your input ! |
…21.5.0 Danny Shemesh (1): Added the keyrings.osx-keychain-keys backend, as discussed in jaraco/keyring#462 Dmitry Shachnev (2): Disable SecretService backend if org.freedesktop.secrets name is not available Disable KWallet backend if org.kde.kwalletd5 name is not available Jason R. Coombs (22): Create Github releases when releasing the package. Fixes jaraco/skeleton#23. Moved refresh.svg to another branch. Reference the animation from the docs. Ref jaraco/skeleton#7. Add the env var mapping too. Disable pytest-black and pytest-mypy on PyPy. Fixes jaraco/skeleton#22. Ref pytest-dev/pytest#7675. Bump black and blacken-docs to latest stable versions. Use enabled plugin configuration to enable mypy and black when the plugin is present. Ref jaraco/skeleton#22. Omit 'return None' as it's implied. Update changelog. Ref #463. Add type hints for KeyringBackend.get_password and .get_credential. I was hoping adding these hints would capture the missed expectation in #463, but alas, they do not. Wrap lines before 80 col. Reword to use imperative voice and give directions in order of execution. Clarify that only passwords created by an executable of Python are relevant. Also enable flake8 and cov when the plugins are present. Add workflows for running tests. Ref jaraco/skeleton#24. Cut releases from Github Actions instead of Azure Pipelines. Ref jaraco/skeleton#24. Refresh docs to prefer Github Actions to Azure Pipelines. Ref jaraco/skeleton#24. Use RTD v2 config Test on Python 3.9. Skip 3.7 to avoid creating too many builds. Release on 3.9. Drop tests on Travis, Appveyor, and Azure Pipelines. use add-github-secrets, which infers the secrets needed from the github workflow. Use inline flags with local scope. Require importlib_metadata 1.0 or later. Fixes #466. Update changelog. 21.4.1 was never released Josh Faust (1): Add a Security Considerations section to the README, with some info about possible issues with the macOS Keychain László Várady (1): Fix return type of KWallet get_credential()
Heya !
For the past few days, I've been working on making webuathn flows to work with OSX's keychain;
During this process, I had to write various wrappers, helpers, and logic that I think would be best served if it were split and contributing to several OSS libraries.
Keyring is the de-facto python standard for accessing OSX keychain - I wonder if you'd be open to the idea of extending the password-oriented interface to storing, retrieving (and potentially signing with) private & public keys;
or alternatively, offering implementations that implement a password interface, and an additional keypair interface.
I have the keychain related logic for it - and not sure this expansion would make sense for every backend.
Let me know if you think this is directionally interesting for the future of keyring, or if it's too far-off the main goal of the library.
Thanks, appreciate your time !
The text was updated successfully, but these errors were encountered: