4 ms·

This goal feels like a marketing OKR to me. A proper technical goal would be "all packages, except the ones that have a valid reason, such as signatures, not to

This goal feels like a marketing OKR to me. A proper technical goal would be "all packages, except the ones that have a valid reason, such as signatures, not to be reproducible".

RegnisGnaw 2y ago
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.
- westurner 2y ago
  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-options https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-opti... 2. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_repository_module.html#parameter-gpgcakey 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 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-repository-signing-in-24-04/42854 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.
0zymandiass 2y ago
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.```
- patrakov 2y ago
  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.
eru 2y ago
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.

This goal feels like a marketing OKR to me. A proper technical goal would be "all packages, except the ones that have a valid reason, such as signatures, not to be reproducible".

RegnisGnaw 2y ago

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.

westurner 2y ago
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-options https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-opti... 2. https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_repository_module.html#parameter-gpgcakey 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 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-repository-signing-in-24-04/42854 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.

0zymandiass 2y ago

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.```

patrakov 2y ago
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.

eru 2y ago

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.