Skip to content
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

Merged
merged 3 commits into from
Feb 27, 2023

Conversation

jlebon
Copy link
Member

@jlebon jlebon commented Feb 16, 2023

create_disk.sh: add more details to secex pubkey user ID

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.


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.

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.
@jlebon
Copy link
Member Author

jlebon commented Feb 16, 2023

/cc @bgilbert in case there's a reason this isn't a good idea.

@nikita-dubrovskii
Copy link
Contributor

LGTM!

Here is a test output from local rhcos-413.92.secex.qcow2 build:

         Starting CoreOS Ignition User Config Setup...
[    2.636378] coreos-secex-ignition-decrypt[795]: gpg: keybox '/tmp/tmp.w4OATSxUsF/pubring.kbx' created
[    2.636770] coreos-secex-ignition-decrypt[795]: gpg: /tmp/tmp.w4OATSxUsF/trustdb.gpg: trustdb created
[    2.636803] coreos-secex-ignition-decrypt[795]: gpg: key 2919EE0D31445760: public key "Secure Execution (secex) 413.92.202302170700-0" imported
[    2.641016] coreos-secex-ignition-decrypt[795]: gpg: key 2919EE0D31445760: secret key imported
[    2.641054] coreos-secex-ignition-decrypt[795]: gpg: Total number processed: 1
[    2.641066] coreos-secex-ignition-decrypt[795]: gpg:               imported: 1
[    2.641078] coreos-secex-ignition-decrypt[795]: gpg:       secret keys read: 1
[    2.641095] coreos-secex-ignition-decrypt[795]: gpg:   secret keys imported: 1
[    2.643201] coreos-secex-ignition-decrypt[805]: gpg: encrypted with cv25519 key, ID 525E96DAA3CC2113, created 2023-02-17
[    2.643235] coreos-secex-ignition-decrypt[805]:       "Secure Execution (secex) 413.92.202302170700-0"
[  OK  ] Finished CoreOS Secex Ignition Config Decryptor.
[    2.645436] systemd[1]: Finished CoreOS Secex Ignition Config Decryptor.

@bgilbert
Copy link
Contributor

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.)

@jlebon
Copy link
Member Author

jlebon commented Feb 22, 2023

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

@bgilbert
Copy link
Contributor

Yeah, probably not. If the single primary key works, that SGTM.

@jlebon
Copy link
Member Author

jlebon commented Feb 22, 2023

Updated!

Yeah, probably not. If the single primary key works, that SGTM.

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.
Copy link
Contributor

@bgilbert bgilbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jlebon jlebon enabled auto-merge (rebase) February 27, 2023 14:55
@jlebon jlebon merged commit d6246b7 into coreos:main Feb 27, 2023
@jlebon jlebon deleted the pr/secex-user-id branch April 22, 2023 23:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants