https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #104 from Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> --- (In reply to Simone Caronni from comment #85) > I need to download all of those keys in one GPG keyring I think it may be better to keep each key in a separate file in Git. Several of those keys will need their expiry dates updated periodically, and any key that expires or gets revoked must be removed from the next release of the package. The keys that are stored in the Fedora Git repository are the trust anchors that the whole verification process hinges on, so changes to the keys should be as transparent as possible. Other packagers should be able to check whether you updated just one key or replaced all the keys with an entirely different set of keys. With a combined keyring, every change looks like the whole keyring is replaced. Comparing the contents of two keyrings requires some pretty advanced GnuPG expertise. With each key as a separate file, any packager can easily see in the Git diff that one key was updated and all the others are unchanged. (In reply to Simone Caronni from comment #90) > - Just checking all keys throws an error due to revoked keys. According to its manpage, gpgv2 does not check whether keys are revoked or expired. Removing those will be your responsibility when you update the package. (In reply to Simone Caronni from comment #91) > I will pipe the output of a script like the one above and just grep for at > least one occurrence of "^gpgv: Good signature from". That will miss any signatures that don't match. A few missing keys is not a problem, but if only one signature matches and all the others come out "bad signature", that should be a big flashing red light. If instead most of the signatures are good but one is bad, that's less alarming but should be investigated before the package is distributed. It may indicate that that person shouldn't be trusted to carefully verify releases, so their key should be removed. (In reply to Suvayu from comment #92) > 1. the instructions on bitcoincore.org say "7. It is recommended that you > choose a few individuals from this list who you find trustworthy and import > their keys ..." > 2. I suggest you choose the person who signed and tagged the release. That makes it equivalent to how they did it before, when only one person signed the releases. The whole point of multiple signatures is to not be reliant on a single person. Here's my proposal for how to check multiple signatures, ignoring missing keys but failing if there are any bad signatures: Source10: key-Someone.gpg Source11: key-Somebody.gpg Source12: key-Other.gpg %global minimum_good_signatures 10 %prep # Collect those sources that are keys for signature verification. for filename in %{sources} ; do case "${filename}" in (*/key-*.gpg) cat "${filename}" ;; esac ; done >combined_keyring.gpg # Verify the signatures. Write machine-readable results to signature_status. Don't fail if a key is missing. gpgv2 --status-fd=3 --keyring=./combined_keyring.gpg SHA256SUMS.asc SHA256SUMS 3>signature_status || true # Fail if there are any signatures that don't match. ! grep --quiet '^\[GNUPG:\] BADSIG ' signature_status # Fail if fewer than the minimum number of signatures are valid. test `grep --count '^\[GNUPG:\] GOODSIG ' signature_status` -ge %{minimum_good_signatures} -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1834731 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
