Skip to content

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

Merged
merged 1 commit into from
Jun 24, 2025

Conversation

mtrmac
Copy link
Collaborator

@mtrmac mtrmac commented Jun 23, 2025

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


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.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Jun 24, 2025

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.

@Luap99
Copy link
Member

Luap99 commented Jun 24, 2025

Are there instructions somewhere on how you generated these? Would be good to have this documented I guess.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Jun 24, 2025

Are there instructions somewhere on how you generated these?

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:

  • Generate new keys
  • Save them using the old format that we use in git (for historical reasons? Anyway this might be a more interoperable way to store the secret keys):
    GNUPGHOME=$(pwd)/signature/fixtures gpg --export-secret-keys > ./signature/fixtures/secring.gpg
    rm -r {signature/simplesigning/testdata,signature/fixtures}/{.gpg-v21-migrated,private-keys-v1.d}
  • For each relevant signature:
    orig=signature/fixtures/expired.signature  # iterate orig through all relevant files
    gpg --list-packets $orig  # along with the file name, determine what needs to happen
    gpg -d $orig | GNUPGHOME=$(pwd)/signature/fixtures gpg --sign --default-key $key_id - > _  # + other parameters as required
    diff -u <(gpg --list-packets $orig) <(gpg --list-packets _) # Check the outcome
    mv _ $orig

... 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>
@mtrmac
Copy link
Collaborator Author

mtrmac commented Jun 24, 2025

Updated to use SHA256, not SHA1 (rejected by Fedora system policies with Sequoia), in the -v3 signatures, ready for merging.

@mtrmac mtrmac marked this pull request as ready for review June 24, 2025 17:26
@Luap99
Copy link
Member

Luap99 commented Jun 24, 2025

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.

Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

LGTM

@mtrmac
Copy link
Collaborator Author

mtrmac commented Jun 24, 2025

It was meant as document which commands you run

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 corrupt signatures need to be manually edited).

@mtrmac mtrmac merged commit 4f38ae2 into containers:main Jun 24, 2025
10 checks passed
@mtrmac mtrmac deleted the rsa3072 branch June 24, 2025 17:46
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.

2 participants