implement a programmatic access to passwords for tools #85
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
the cli should support a way to provide passwords to applications to allow replacement of .env files. this API access of course needs a separated access pathway that is not the actual gpg key passphrase but uses system supported ways to authorize access to passwords that way. For example keychains or things like that. This has to be explored more, so that we can provide solutions to all target systems.
Setup of access permissions must be handled inside the password storage, so that multiple different ways handle external identities and their permissions the same way. This will require access key generation and secure storage of those access keys for those external identities so that the usage can be done even if offline.
The whole idea would be a synchronized identity store for identities and associated secrets that crosses platforms and also network access. This heavily hinges on a safe way for a local daemon to handle all the access and auth stuff against the storage without exposing the gpg key passphrase outside.
The later stage should also include proper REST API for acces from different languages, so that they can safely fetch allowed passwords and otp keys from that local daemon.
If possible, the local daemon or background tool should use biometric checks to make sure that initial setup is done with proper authentication, but after setup and start it should run uninterrupted. It might be needed to support a fully-automatic way for actual system services to work, too.
We need a good plan and backlog for this as its own milestone, fully fleshed out, with proper look on security.