As someone who dabbles a bit in the RHEL world, IIRC all packages in Fedora are signed. In additional the DNF/Yum meta-data is also signed.

IIRC I don't think Debian packages themselves are signed themselves but the apt meta-data is signed.

I learned this from an ansible molecule test env setup script for use in containers and VMs years ago; because `which` isn't necessarily installed in containers for example:

  type -p apt && (set -x; apt install -y debsums; debsums | grep -v 'OK$') || \
  type -p rpm && rpm -Va  # --verify --all

dnf reads .repo files from /etc/yum.repos.d/ [1] which have various gpg options; here's an /etc/yum.repos.d/fedora-updates.repo:

  [updates]
  name=Fedora $releasever - $basearch - Updates
  #baseurl=http://download.example/pub/fedora/linux/updates/$releasever/Everything/$basearch/
  metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
  enabled=1
  countme=1
  repo_gpgcheck=0
  type=rpm
  gpgcheck=1
  metadata_expire=6h
  gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
  skip_if_unavailable=False

From the dnf conf docs [1], there are actually even more per-repo gpg options:

  gpgkey
  gpgkey_dns_verification
  
  repo_gpgcheck
  localpkg_gpgcheck
  gpgcheck

1. https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-opti...

2. https://docs.ansible.com/ansible/latest/collections/ansible/... lists a gpgcakey parameter for the ansible.builtin.yum_repository module

For Debian, Ubuntu, Raspberry Pi OS and other dpkg .deb and apt distros:

  man sources.list
  man sources.list | grep -i keyring -C 10
  # trusted:
  # signed-by:
  # /etc/apt/ trusted.gpg.d/
  man apt-secure
  man apt-key
  apt-key help
  less "$(type -p apt-key)"

signing-apt-repo-faq: https://github.com/crystall1nedev/signing-apt-repo-faq

From "New requirements for APT repository signing in 24.04" (2024) https://discourse.ubuntu.com/t/new-requirements-for-apt-repo... :

> In Ubuntu 24.04, APT will require repositories to be signed using one of the following public key algorithms: [ RSA with at least 2048-bit keys, Ed25519, Ed448 ]

> This has been made possible thanks to recent work in GnuPG 2.4 82 by Werner Koch to allow us to specify a “public key algorithm assertion” in APT when calling the gpgv tool for verifying repositories.

If you'd bothered to read:

```This definition excludes signatures and some metadata and focuses solely on the payload of packaged files in a given RPM:

    A build is reproducible if given the same source code, build environment and build instructions, and metadata from the build artifacts, any party can recreate copies of the artifacts that are identical except for the signatures and parts of metadata.```

The same LWN article says:

> The contents, however, should still be "bit-by-bit" identical, even though that phrase does not turn up in Fedora's definition.

So, according to the literal interpretation of the article, signatures inside the payload (e.g., files that are signed using an ephemeral key during the build, NOT the overall RPM signature) are still a self-contradictory area and IMHO constitute a possibly-valid reason for not reaching 100% payload reproducibility.

At Google SRE we often had very technical OKRs that were formulated with some 'number of 9s'. Like 99.9999% uptime or something like that. So getting two 9s of reproducibility seems like a reasonable first goal. I hope they will be adding more nines later.