gpgv2 does not work with the openpgp key format. Use gpg --verify or issue a warning that the openpgp key format should not be used. Reproducible: Always Steps to Reproduce: 1. Try to verify a source in a spec file using a key in openpgp key format 2. 3. Actual Results: Source does not verify Expected Results: Source should verify https://lists.nongnu.org/archive/html/skribilo-users/2023-07/msg00000.html
Happy to make a pull request to https://src.fedoraproject.org/rpms/redhat-rpm-config though may invalidate https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/84
The referenced mailing list thread is really light on technical details. I believe `gpgv` is the right tool to use here. Why, exactly, isn't it working?
Based on https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/gpgverify tried the following commands mkdir testgpg cd testgpg # Get the keys wget https://systemreboot.net/about/arunisaac.pub wget https://keys.openpgp.org/vks/v1/by-fingerprint/7F730343F2F09F3C77BF79D32E25EE8B61802BB3 # From https://superuser.com/questions/1641291/gpg-only-download-a-key-from-a-keyserver gpg --keyserver keyserver.ubuntu.com --recv-keys 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 && gpg --export armour 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 > 0x7f730343f2f09f3c77bf79d32e25ee8b61802bb3.gpg && gpg --batch --yes --delete-keys 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 wget https://download.savannah.nongnu.org/releases/skribilo/skribilo-0.10.0.tar.gz.sig wget https://download.savannah.nongnu.org/releases/skribilo/skribilo-0.10.0.tar.gz mkdir ar mkdir 0x mkdir 7F gpg2 --homedir=0x --yes --output=0x/keyring.gpg --dearmor 0x7f730343f2f09f3c77bf79d32e25ee8b61802bb3.gpg gpg2 --homedir=ar --yes --output=ar/keyring.gpg --dearmor arunisaac.pub gpg2 --homedir=7F --yes --output=7F/keyring.gpg --dearmor 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 Then try to verify the keys $ gpgv2 --homedir=0x --keyring=0x/keyring.gpg skribilo-0.10.0.tar.gz.sig skribilo-0.10.0.tar.gz gpgv: Signature made Wed 08 Mar 2023 04:11:11 AM EAT gpgv: using RSA key 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 gpgv: Good signature from "Arun I <arunisaac>" $ gpgv2 --homedir=ar --keyring=ar/keyring.gpg skribilo-0.10.0.tar.gz.sig skribilo-0.10.0.tar.gz gpgv: Signature made Wed 08 Mar 2023 04:11:11 AM EAT gpgv: using RSA key 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 gpgv: Good signature from "Arun I <arunisaac>" $ gpgv2 --homedir=7F --keyring=7F/keyring.gpg skribilo-0.10.0.tar.gz.sig skribilo-0.10.0.tar.gz gpgv: Signature made Wed 08 Mar 2023 04:11:11 AM EAT gpgv: using RSA key 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 gpgv: Can't check signature: Bad public key $ gpg --verify --openpgp --homedir=7F --keyring=7F/keyring.gpg skribilo-0.10.0.tar.gz.sig gpg: WARNING: unsafe permissions on homedir '/home/benson/Projects/FedoraPackaging/my-packages/skribilo/skribilo10/7F' gpg: assuming signed data in 'skribilo-0.10.0.tar.gz' gpg: Signature made Wed 08 Mar 2023 04:11:11 AM EAT gpg: using RSA key 7F730343F2F09F3C77BF79D32E25EE8B61802BB3 gpg: Good signature from "[?]" gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 7F73 0343 F2F0 9F3C 77BF 79D3 2E25 EE8B 6180 2BB3 The issue is that keys can have several different formats, so being able to specify compliance options would be helpful. From the man pages Compliance options These options control what GnuPG is compliant to. Only one of these options may be active at a time. Note that the default setting of this is nearly always the correct one. See the INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS sec‐ tion below before using one of these options. --gnupg Use standard GnuPG behavior. This is essentially OpenPGP behavior (see --openpgp), but with extension from the proposed update to OpenPGP and with some additional workarounds for common compatibility problems in different versions of PGP. This is the default option, so it is not generally needed, but it may be useful to override a different compliance option in the gpg.conf file. --openpgp Reset all packet, cipher and digest options to strict OpenPGP behavior. This option implies --allow-old-ci‐ pher-algos. Use this option to reset all previous options like --s2k-*, --cipher-algo, --digest-algo and --compress-algo to OpenPGP compliant values. All PGP workarounds are disabled. --rfc4880 Reset all packet, cipher and digest options to strict RFC-4880 behavior. This option implies --allow-old-ci‐ pher-algos. Note that this is currently the same thing as --openpgp. --rfc4880bis Reset all packet, cipher and digest options to strict according to the proposed updates of RFC-4880. --rfc2440 Reset all packet, cipher and digest options to strict RFC-2440 behavior. Note that by using this option en‐ cryption packets are created in a legacy mode without MDC protection. This is dangerous and should thus only be used for experiments. This option implies --allow-old-cipher-algos. See also option --ignore-mdc-error. --pgp6 This option is obsolete; it is handled as an alias for --pgp7 --pgp7 Set up all options to be as PGP 7 compliant as possible. This allowed the ciphers IDEA, 3DES, CAST5,AES128, AES192, AES256, and TWOFISH., the hashes MD5, SHA1 and RIPEMD160, and the compression algorithms none and ZIP. This option implies --escape-from-lines and disables --throw-keyids, --pgp8 Set up all options to be as PGP 8 compliant as possible. PGP 8 is a lot closer to the OpenPGP standard than previous versions of PGP, so all this does is disable --throw-keyids and set --escape-from-lines. All algo‐ rithms are allowed except for the SHA224, SHA384, and SHA512 digests. --compliance string This option can be used instead of one of the options above. Valid values for string are the above option names (without the double dash) and possibly others as shown when using "help" for string. --min-rsa-length n This option adjusts the compliance mode "de-vs" for stricter key size requirements. For example, a value of 3000 turns rsa2048 and dsa2048 keys into non-VS-NfD compliant keys. --require-compliance To check that data has been encrypted according to the rules of the current compliance mode, a gpg user needs to evaluate the status lines. This is allows frontends to handle compliance check in a more flexible way. However, for scripted use the required evaluation of the status-line requires quite some effort; this option can be used instead to make sure that the gpg process exits with a failure if the compliance rules are not fulfilled. Note that this option has currently an effect only in "de-vs" mode.
It looks to me that the gpg import/export corrupts the key. For me, curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x7f730343f2f09f3c77bf79d32e25ee8b61802bb3' | gpg2 --dearmor produces a key that is directly usable with gpg2v, and can verify the signature on skribilo-0.10.0.tar.gz. This doesn't seem to be a problem with gpg2v.
It seems one cannot pass options into gpgv2 to specify the standard used for the gpg key, whereas one can pass options into gpg --verify. Maybe helpful to produce a warning that keys should be compatible with gnupg which is different from openpgp.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
Using gpg2 --verify (or gpg --verify) would be problematic. It expects that the user has a keyring with a mix of trusted and untrusted keys, and wants to use key signatures to determine which keys to trust. It will also complain if the key has expired. When building RPM packages we want to provide a keyring with only trusted keys, and we don't want rebuilds to start failing just because the clock has ticked past an expiry date. That's exactly the usecase gpgv2 (or gpgv) is made for. It seems that keys.openpgp.org redacts user IDs as described in this expired Internet-draft: https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-abuse-resistant-keystore-06#section-5.1 GnuPG on the other hand considers a user ID a mandatory part of an OpenPGP key, as stated by Werner Koch in this debate: https://dev.gnupg.org/T4393#133689 The Internet-draft agrees that a key without a user ID is technically invalid, and discusses how the missing user ID can be found or synthesized. Looking up a key by fingerprint on keys.openpgp.org would be "certificate discovery with redacted user IDs" like in section 5.1.2 of the Internet-draft. From the referenced mailing list thread I get the impression that you looked up the key using a fingerprint taken from the signature. Doing that *only once* is a form of "trust on first use". If you do it every time a release is signed by an unknown key, then you render the whole verification exercise pointless, as all you verify is that the tarball was signed by whoever signed the tarball. An attacker can then sign a malicious tarball with their own key, and you'll fetch the attacker's key and verify the signature as usual. The Skribilo project should publish a collection of authorized release-signing keys in some form, so that you can know which keys to include in your package. They *could* do it by publishing only the fingerprints on their website and pointing you to a keyserver where you should look up the keys, but that's unnecessarily complicated for the packager. Publishing key files on their website works better. Then you can put the full URL in the spec file, so that others reading the spec can see where you got the key from, and the developers avoid having their user IDs redacted by keys.openpgp.org. Currently gpgverify wants all the trusted keys in a single keyring. Arun Isaac thought that keeping such a keyring updated could be a pain. This improved version of gpgverify accepts multiple separate key files: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261
Why does Bugzilla make random changes to several fields when I only add a comment?
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.