On 29/11/2022 09:24, Bob Hepple wrote: On Fedora you must upload source tarball, its signature and public key to the Fedora look-aside cache, because builders have no network access for security reasons. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

Vitaly Zaitsev via devel wrote: A minor expansion on that; the public key / upstream keyring must be be stored in dist-git rather than in the lookaside cache, per the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_sig... 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. One of reasons being that it's (at least slightly) easier to notice a change to the public key / keyring when it's in dist-git versus the lookaside cache. -- Todd

On Tue, Nov 29, 2022 at 2:50 PM Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; wrote: If they're ASCII armored format, then store them in Git, by all means. Even with storing in the lookaside, we'd know when they change because the checksum in the sources file changes. -- 真実はいつも一つ！/ Always, there's only one truth!

Vitaly Zaitsev via devel wrote: Why is that? Does 8-bit data break Git somehow? A key is a small file. It doesn't bloat the repository like a tarball would. When a key needs replacing, the new key is entirely different whether it's ASCII-armored or not, so there's nothing to gain by storing a diff instead of the whole file. ASCII-armor is for sending messages over old 7-bit protocols, just like Base64 and UUencoding. In 8-bit-clean channels ASCII-armor doesn't accomplish anything other than making the message slightly larger. I can't believe that Git wouldn't be 8-bit-clean. Björn Persson

Bob Hepple wrote: As the builders lack Internet access, they can't pull directly from the upstream Git repository. To verify a signed Git tag during the build, it would be necessary to package up the whole Git repository (or enough of it to include the source code, the tag and the signature) and upload that instead of the source tarball. Then I suppose you would unpack the repository in %prep and run some Git command to verify the signature, probably "git verify-tag" which is described as "check the GPG signature of tags". gpgverify uses the command gpgv instead of gpg. It's a simplified verification method that fits this usecase better. If Git calls gpg and expects to find a keyring in the user's home directory, then you'd have to write the spec to prepare a suitable keyring, ensure that GnuPG will find that and no other keyring, and tell it to trust the correct key. It's far from trivial to get that right and secure. I'm not aware of any tooling for this other than gpgverify, so I suppose the answer is that Fedora does not support signed Git tags. It should also be noted that with gpgverify we verify the signature before we unpack the tarball. If a malicious tarball tries to attack some vulnerability in Tar or Gzip, then either the verification will fail and stop the build before the attack gets a chance to work, or else the tarball was already malicious when the upstream developer signed it. With Git I don't know how we could avoid unpacking the repository archive before we verify the signed tag. As to why the builders lack Internet access, I wasn't around when that was decided but it helps ensure that the source RPM packages actually contain the source code. Björn Persson

On Tue, Nov 29, 2022 at 3:24 AM Bob Hepple <bob.hepple(a)gmail.com&gt; wrote: Arch Linux has internet access in their builders. Their PKGBUILD files can fetch content from the internet as part of their build process. That's why they can do that. Neither Fedora, nor Debian, nor Ubuntu, nor openSUSE would allow that. -- 真実はいつも一つ！/ Always, there's only one truth!