GPG signature checks for upstream tarballs

[tithom]

Hello all,

I tried to search on the wiki and this forum but could not find answers easily, so I hope that it's not a duplicate.

I have two related questions regarding security of upstream releases following the xz backdoor. I use Fedora on my main laptop, and I have some experience with OpenBSD, Arch and Gentoo. When comparing how each deal with upstream, hopefully not making any major mistakes:
- OpenBSD, I try to keep it as vanilla as possible, eg. not install any additional packages although that is less easy to do on a work laptop. The package makefiles seem to be quite similar to the ebuilds of Gentoo with the sha256 of the package recorded though I'm not sure where are the packages built.
- Arch Linux downloads the tarball, check the GPG signature (see for instance makepkg of KeepassXC here with the validpgpkeys array and compile on either dev machines or some dedicated build machine. I have not yet found some comprehensive information on this topic, see one such post that I could find. Some issues could then happen at build time but they are also well advanced with reproducible build, see there. So if the GPG checks out (when provided by upstream) and the build checks out, I'd assume that the binary is relatively "safe". Then remains the fact that the binaries are very recent with Arch and so if something like the xz backdoor happens, odds are that it won't be caught up in time.
- For Fedora, as far as I understand, the packager uploads the spec file and the tarball to the build system and the binaries are built in an isolated environment without network access (provided by systemd-spawn if I'm not wrong). They are working on reproducible builds and, from checking a few packages which I would think are security sensitive (oath-toolkit, wireguard-tools, keepassxc), GPG checks are less common than the equivalent Arch packages (example of package checked there with the macro %{gpgverify}). Staying one Fedora version behind should help mitigating malicious upstream commits (well, not bullet proof at all, but certainly less on the front lines than Arch).

Gentoo is very attractive to me (since I installed it once before). In general, I've been bouncing back and forth between Fedora and Arch. Gentoo would seem like a happy compromise:
- Rolling, but packages older than Arch's if not on ~ yet ability to have a few more recent packages (eg. browsers, DE)
- Configure packages and ability to trim down unused features (I spent a great deal of time trying to change some out of the box features of Fedora such as unmasking the grub boot menu, configuring snapper, removing unnecessary packages from the default install - admittedly that was before finding out about the netinstall)
- Mix n match binaries and compiled packages (workable on Arch but probably if the compiled packages are a minority, have not yet tried on Fedora)
- Probably one of the distros the most compatible with SELinux - though I may consider AppArmor instead

So now to the questions I'd have:
- Are Gentoo binaries compiled onto dedicated machines / in isolated containers? Would Gentoo plan to support reproducible build for binaries? Are they build from the same ebuild file available on gitweb?
- Is checking gpg signatures of tarball supported by the ebuilds? If not, would packagers typically check the gpg signatures before the blake 2 sum is included? Of course, it's always possible to download the package manually, check the gpg sig & cross check the blake 2 sum, but that'd be pretty difficult for many packages.
- I think that I read somewhere that most packages are checked by 2 Gentoo devs, but I'm not so sure

Now, I understand that the risks are probably small, and that it's far from the biggest threat. But I'm trying to improve my security setup with each new iteration / change and taking opportunities to learn at each new step.

Many thanks in advance

[sam_]

[tithom]

Thanks a lot for the detailed response!

So the ebuilds I checked did not include gpg checks, I tried my luck with shadow and it does have verify-sig.

For packages missing it when upstream releases it, would it be appropriate to open a bug report or some other types of notifications?

That is great and one step closer to diving back.

[sam_]

No problem.

I think it depends on the upstream, how easy they make it to verify, and if the package maintainer is willing to take it.

verify-sig is a fairly new thing still (last few years) and adoption is slowly increasing.

Personally, I'd be fine with any reports telling me that PGP signatures are available for tarballs for my packages, although I'd be more likely to act on it (at least sooner) if you can link me to a convenient location for the upstream maintainer's keyring too. Pull requests / patches are even better.