-
Notifications
You must be signed in to change notification settings - Fork 165
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
create_disk.sh: add more details to secex pubkey user ID and remove expiration #3362
Conversation
Include "Secure Execution" since `secex` might be too cryptic. Still keep `secex` as an easy and stable handle to use. Include the build ID the key is associated with to make it easier to tell apart multiple secex keys.
The default is 2 years, which is much too short for us since we theoretically need to support arbitrarily old bootimages. We don't want users to have to e.g. fake the system time to work around this. Anyway, since the keys are build-specific and will otherwise not be trusted anywhere else, it seems reasonable to just not have an expiry date at all.
/cc @bgilbert in case there's a reason this isn't a good idea. |
LGTM! Here is a test output from local
|
Good catch! Note that in the cosa container this is generating ed25519 keys, not RSA. By using the defaults, we're also allowing GPG to change the key types in future. I'd suggest explicitly specifying the key types. For example, for RSA4096: gpg2 --homedir . --batch --passphrase '' --yes --default-new-key-algo rsa4096/cert+rsa4096/encr --quick-gen-key "Secure Execution (secex) $buildid" default default none (That also removes the "signing" usage flag from the primary key, since I don't think we'll be doing any of that.) |
Good catch re. defaults changing under us. Hmm, for this use case, does it make sense to have a primary key and subkey at all rather than a single primary key? The latter would be: gpg --homedir "${tmp_home}" --batch --passphrase '' --yes \
--quick-gen-key "Secure Execution (secex) $buildid" rsa4096 encr none |
Yeah, probably not. If the single primary key works, that SGTM. |
Updated!
Edit: forgot to add, I did test this works for encrypting and decrypting when manually playing with a temporary GPG homedir. |
Otherwise, we'll just use whatever the default GPG algorithm is, which could change in the future. While we're here, mark the key's usage as encryption only since that's all we need it for.
c1ef8ae
to
c2ef6a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
create_disk.sh: add more details to secex pubkey user ID
Include "Secure Execution" since
secex
might be too cryptic. Stillkeep
secex
as an easy and stable handle to use. Include the build IDthe key is associated with to make it easier to tell apart multiple
secex keys.
create_disk.sh: don't set an expiry date on secex pubkey
The default is 2 years, which is much too short for us since we
theoretically need to support arbitrarily old bootimages. We don't want
users to have to e.g. fake the system time to work around this. Anyway,
since the keys are build-specific and will otherwise not be trusted
anywhere else, it seems reasonable to just not have an expiry date at
all.