-
-
Notifications
You must be signed in to change notification settings - Fork 377
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 TPM-backed signing key storage #953
Comments
This issue is provided largely as a discussion piece. I'm happy to do work on this ticket myself, but want to be sure we've had enough up-front discussion to have reason to believe that it's likely to be considered mergable in-principle before going beyond a simple proof-of-concept. |
(One important caveat, while we're talking about upstream acceptability: It may be necessary to fork or vendor and patch https://pkg.go.dev/golang.org/x/crypto/openpgp -- at least, I had cause to do so last time I worked on something like this). |
tpmk
library exists to allow TPM-backed keys to be operated on from Go.Aptly should support signing packages with tpmk-backed keys; this way, even a user with all the privileges aptly itself has won't be able to copy that key off and put it to their own uses in the future (but will need to have a persistent compromise of a repo-signing server lasting for the entire duration of time in which they wish to corruptly/incorrectly sign keys).
Detailed Description
The proposal is to add an alternative to the current practice of passing a signing key (or a path to a signing key) and a password to aptly. For example, we might recognize a
SecretKeyring
of the formtpm:0x81000000
as an instruction to ask the tpmk to load a private key from the given address.Context
This change will make it possible to trust users to use aptly without giving them enough permissions to impersonate that aptly server in the future.
The text was updated successfully, but these errors were encountered: