Frank R Dana Jr. wrote: > Here's what the docs say: [...] > > 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 You're confusing two different things here: 1: A file can be stored either in the Git repository or in the "lookaside cache" (which is not a cache in the usual computing sense, but more of a repository). As I understand it, there was a desire to avoid storing an ever-growing sequence of big blobs in Git, so a separate repository for source tarballs was created. 2: A Source tag can be either a URL or just a filename. If it's possible to download a file with a URL, then you should show the URL so others can know where you got the file from. If there is no URL, then you can't do that, and you should instead explain in a comment where the file came from. Those two things are orthogonal. Whether a file fits best in the Git repository or the side repository has nothing to do with whether a URL to the file exists. > 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? That's what it says, yes. I guess the idea is to keep the chain short. No chain is stronger than its weakest link, so reducing the number of links reduces the risk of the chain breaking. A file in the "lookaside cache" can be verified against a hash in a file in the Git repository. If that verification would turn out to be a weak link, then a file stored directly in Git would be unaffected by that weakness. Keyrings are small files, typically smaller than a spec file. (You shouldn't trust hundreds of keys to sign releases for a single upstream project.) Keyrings are also not supposed to change with every release, like tarballs do. The whole point is to verify that each new release is signed with the same trusted key (or one of a small number of trusted keys). Thus storing keyrings in Git shouldn't cause any problems. As for "manually downloaded", there's no difference there. Source tarballs must also be downloadad. > 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. It says "if they publish only a fingerprint". In that case that's where the ID string comes from. If they don't publish even that, then perhaps you can ask them? To see how difficult it would be to ask a question, I followed your link [2], clicked on "Personal" and then "Contact Form" – where I found a "public key" link. Bingo! We don't need to use the contact form after all. But let's pretend that that file and the contact form don't exist, and turn this into a hypothetical question: What to do if there is no key and no fingerprint, and the upstream author flat out refuses to communicate? If all else fails, one can as a last resort do the detective work you did: > 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. Now you have the key that the tarball was signed with. If the tarball you have is genuine, then you probably have the correct key. If the tarball is malicious, then the key you found is the attacker's key. At this stage you can't tell the difference, but going forward you can at least check that each new release is signed with the same key. This is called "trust on first use", TOFU. It's better to be able to verify the key, but TOFU can at least build trust over time if the key is stable. What you absolutely *MUST NOT* do is repeat the above process for every release and replace the keyring. That way you'd just overwrite the real key with the attacker's key when there is an attack, and no security whatsoever would be gained. End of the hypothetical scenario. Now you should go download the key from the website and check that it matches the one you found on the keyserver. Björn Persson
Attachment:
pgpxCOucWforJ.pgp
Description: OpenPGP digital signatur
-- _______________________________________________ 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
