-
Notifications
You must be signed in to change notification settings - Fork 402
Regenerate keys TestKeyFingerprintWithPassphrase and TestKeyFingerprint #2875
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
Conversation
Validation: Checked, using ls -lt $(grep -lr 'BEGIN' signature | grep -v sequoia/rust) and ls -lt $(for i in $(find signature -type f | grep -v 'sequoia/rust\|pgp.cert.d\|/softkeys/' ); do if (od -An -tx1 < $i| read x; echo "$x" | cut -c 1 | grep -q '[89abcdef]') ; then echo "$i"; fi; done) (looking for files which start with OpenPGP packets, all of which have the leading bit set) that all signature / key files have been updated, or don’t need to be. |
Are there instructions somewhere on how you generated these? Would be good to have this documented I guess. |
Sadly, no. “It would have been a good idea”, but, also, I’d rather not spend time re-automating that now. The basic process was:
|
... to use 3072-bit RSA keys instead of 1024-bit, and thus hopefully comply with recent crypto policies without extra setup. Continue to use RSA for both keys: - Passphrase-protected ed25519 keys seem to have interoperability issues with Sequoia ( https://gitlab.com/sequoia-pgp/sequoia/-/issues/1194 ) - The non-passphrase-protected key needs to be usable in v3 signature packets, and those seem not to be defined for ed25519 The v3 signature packets need to be generated using GnuPG < 2.1.0, in this case it was done 2.0.22 . It would have been a good idea to script the creation of keys and signatures, in retrospect, but if the first step is "install a 12-year-old OS", that would not be _that_ valuable. The next time, if any, we would probably leave the current RSA key and v3 signatures unchanged, and use a more recent algorithm for new keys and tests. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Updated to use SHA256, not SHA1 (rejected by Fedora system policies with Sequoia), in the |
My comments was not meant to suggest to automate that (which I agree would always be nice). It was meant as document which commands you run (for this PR) to regenerate the files so at least the next time it is needed someone has a place to start. |
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
Yes — the above is the gist of it, to list the affected files and to re-sign, but there a bit of manual tinkering (e.g. the |
... to use 3072-bit RSA keys instead of 1024-bit, and thus hopefully comply with recent crypto policies without extra setup.
Continue to use RSA for both keys:
The v3 signature packets need to be generated using GnuPG < 2.1.0, in this case it was done 2.0.22 .
It would have been a good idea to script the creation of keys and signatures, in retrospect, but if the first step is "install a 12-year-old OS", that would not be that valuable. The next time, if any, we would probably leave the current RSA key and v3 signatures unchanged, and use a more recent algorithm for new keys and tests.
Marked as draft:
signature/fixtures/expired.signature
did not, yet, expire (and I can’t remember any more how I previously managed to create an “expires in 0 seconds” signature), so the related tests are failing. They should start succeeding in 13 hours.