jqlang
SHA1 used in Release Key
Describe the bug
The GPG Key used to sign jq releases appears to use an SHA1-based self-signature, meaning it will cause errors and failures on GPG configurations that adopt modern and widely recommended standards.
To Reproduce
① Configure GPG to use weak-digest SHA1 (the current best practice)
② Import the release key into your GPG Keyring
③ Refresh the keys
Actual behavior
GPG errors out stating:
gpg: Note: signatures using the SHA1 algorithm are rejected
[…]
gpg: key 0xAF19040C71523402: invalid self-signature on user ID "jq Release Signing Key <[email protected]>"
gpg: key 0xAF19040C71523402: skipped user ID "jq Release Signing Key <[email protected]>"
gpg: key 0xAF19040C71523402: no valid user IDs
Expected behavior
The release key should follow long-established best-practices and replace weak algorithms by newer and more temper-resistant versions. While the actual risk to jq users is admittedly very low, having this one release key stick out could necessitate that server admins lower the overall security of their GPG environment by accepting SHA1-signed keys. This could quickly snowball and create larger-scale security issues.
@nicowilliams Would you take this issue please? If you could improve the release job to commit and push signatures, that would be great.
@itchyny should we maybe commit the private key encrypted in a high-entropy passphrase and then set up the GHA to have access to the passphrase to sign releases? Or maybe we should do that in a private clone of jq in the org? How do other projects handle this?
@nicowilliams We can use Action Secrets for both private key and passphrase. I think we can use ghaction-import-gpg to import the release key. One of the famous releasing actions for Go, goreleaser-action also recommends to use this ghaction-import-gpg action for GPG signing. In order to minimize the risk of malicious usage, make sure to use Environment secrets. I've just created the release environment so store there, and add environment: release to the release job.
@itchyny is there a way to get an email address for a repository that we could use for the new release key? The old release key is named jq Release Signing Key <[email protected]>, but clearly that's bunk, though I figure clue-ful people can figure out how to find our issues page from jq Release Signing Key <[email protected]>.
I've generated and add a release key. Which workflows should import and use it to sign artifacts? Maybe we only want to sign artifacts on jq-*. Also, maybe we should have a nightly build and release?
@nicowilliams Thanks! Sorry for the delay to notice the mention, I was thinking of using noreply@ would be better to notify users that they can't receive reply (if re-generating is a tough work, that's okay). I learned about GPG signing last week, and was actually trying to setup the release job to push the signature (but you're updating the public key is necessary). Do we need to re-sign all the existing signatures? Or keep jq-release.key and add jq-release-v2.key (ah, maintaining/documenting is hard)?
noreply@ sounds good. Maybe we could even go with [email protected] :) -- it's not just that we won't reply, but that no one should even send email there.
Do we need to re-sign all the existing signatures?
We could add a second signature with the new key, but first let's release 1.7. We're very close. I think the only blocker is that we need to rip out -0 and maybe a bit more.