The Packaging Guidelines have a section on "Source File Verification"[1] which is probably sufficient for the ideal case where the upstream publishes their keyring, but it seems to be lacking steps for the (probably MORE common) scenario where that's not the case. Take the pv utility[2]. Fairly typically, signatures are published alongside the source tarballs, but that's all. The docs ALLOW for that possibility, but they don't even make it halfway to the finish line in documenting how to properly handle it. Here's what the docs say: > Ideally the upstream project publishes such a keyring as a downloadable file. Yeah, OK, but most don't. > Any detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) > must be uploaded to the package lookaside cache alongside the > source code, while the keyring must be committed directly to the > package SCM. Now, even in the ideal case this seems like a potential source of confusion, because the example specfile lines that immediately follow that statement are: > Source0: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.gz > Source1: ftp://ftp.example.com/pub/foo/%{name}-%{version}.tar.gz.asc > Source2: https://www.example.com/gpgkey-0123456789ABCDEF0123456789ABCDEF.gpg So, does that mean that remote keyrings should be listed at their source URL, BUT the `gpgkey-` file at that URL should be manually downloaded and `git add`-ed to the package repo? Because if so, that's an atypical situation that deserves a lot more explanation than the current vague handwave. (Especially considering how heavily packagers are beaten over the head with the rule that they should NEVER check package sources in to the repo. If this is the one circumstance that breaks that rule, then that needs to be MUCH more clearly and explicitly stated.) ...Anyway — going back to my non-ideal case. Since I don't have a keyring file or URL for pv, just a tarball and a signature, I need to read on. This non-ideal scenario is covered a bit later: > If the upstream project does not publish a keyring file > (for example if they publish only a fingerprint on their website > and refer to a keyserver network for downloading the key), > then you may need to create a keyring after you have verified > the key. In this case there is no upstream URL to the keyring, > so instead you should document how you created the keyring > in a comment in the spec file. A minimal keyring with the key > with the fingerprint 7D33D762FD6C35130481347FDB4B54CBA4826A18 > can be created with the following command: > > gpg2 --export --export-options export-minimal \ > 7D33D762FD6C35130481347FDB4B54CBA4826A18 \ > > gpgkey-7D33D762FD6C35130481347FDB4B54CBA4826A18.gpg ...OK, wait, go back. It's great that I have a command for generating a keyring file for key 7D33Dwhatever, but where the heck did that ID string even COME from??? Never explained. In my case for pv, here's what I did: 1. Used gpgv2 to examine the signature (it expectedly failed to verify it): $ gpgv2 pv-1.8.13.tar.gz.txt pv-1.8.13.tar.gz gpgv: Signature made Sun 18 Aug 2024 05:06:28 PM EDT gpgv: using RSA key 4267B4F90F2678A112169BD61D1EF7581B45E9A0 gpgv: issuer "andrew.wood@xxxxxxxxxx" gpgv: Can't check signature: No public key That at least got me a key ID, which is progress. Then, because I can never figure out the correct gpg commands to do anything, I launched Seahorse and ran a keyserver search for 4267B4F90F2678A112169BD61D1EF7581B45E9A0. That got me Andrew Wood's public key (ID 1D1EF7581B45E9A0), and I imported it into my local keyring. NOW I was in a position to run the export command from the docs: $ gpg2 --export --export-options export-minimal 1D1EF7581B45E9A0 \ > gpgkey-1D1EF7581B45E9A0.gpg ...And I finally have a gpgkey- file I can check into the source tree and add to the spec file so I can enable signature verification. But a Seahorse-based graphical search and import isn't really practical for packager workflows in general, and holy smokes was the documentation almost no help at all in actually guiding me to the finish line here. [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification [2]: https://www.ivarch.com/programs/pv.shtml -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
