Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#80266 - [certbot] Issue with .BUILDINFO in recent versions

Attached to Project: Arch Linux
Opened by Iyan (iyanmv) - Wednesday, 15 November 2023, 21:45 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:21 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jelle van der Waa (jelly)
George Rawlinson (rawlinsong)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

It would be nice to make all certbot-* packages reproducible. It is critical software managing TLS certificates, and in Debian all these packages are marked as reproducible (see, for example, https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/python-certbot.html).

However, in the Arch Linux `rebuilderd` instance (https://reproducible.archlinux.org/), they are all marked as unreproducible.

The logs show that `archlinux-repro` fails to build the package because there is a discrepancy between the PKGBUILD and .BUILDINFO in recent versions (`certbot>2.6.0-1`). PKGBUILD contains `"python-acme=$pkgver"` in the depends array, so both PKGBUILD and .BUILDINFO should include the same version of `python-acme`, synced with the `pkgver` of the package. This is not the case for the last released packages.

Current package in the repos, certbot-2.7.4-1-any.pkg.tar.zst has `installed = python-acme-2.7.2-1-any` instead of `installed = python-acme-2.7.4-1-any`. Same issue can be checked for certbot-2.7.2-1-any.pkg.tar.zst (https://archive.archlinux.org/packages/c/certbot/certbot-2.7.2-1-any.pkg.tar.zst)


Steps to reproduce:

The issue can be reproduce locally:

```
curl -OL https://archive.archlinux.org/packages/c/certbot/certbot-2.7.4-1-any.pkg.tar.zst
repro certbot-2.7.4-1-any.pkg.tar.zst
```

However, I cannot reproduce how the wrong version of `python-acme` ended up in the recent .BUILDINFO files.
For example, running this:

```
pkgctl repo clone --protocol=https --switch 2.7.2-1 certbot
cd certbot
pkgctl build --clean --pkgver=2.7.4
```

Generates the correct package, with the right python-acme, and it is reproducible.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:21 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/certbot/issues/1
Comment by Iyan (iyanmv) - Wednesday, 15 November 2023, 22:45 GMT
For future readers interested in R-B, after discussing with anthraxx and kpcyrd in #archlinux-reproducible I think I now understand how the wrong version of python-acme ended up in .BUILDINFO.

1. pkgctl repo clone --protocol=https --switch 2.7.2-1 certbot
2. Update $_commit variable b62133e3e19367b82b5fde3d5f5ad97e6ced5447, but leave $pkgver unmodified
3. Download python-acme 2.7.2-1 from archive: https://archive.archlinux.org/packages/p/python-acme/python-acme-2.7.2-1-any.pkg.tar.zst
4. Run pkgctl build -I python-acme-2.7.2-1-any.pkg.tar.zst

This produces a certbot-2.7.4-1-any.pkg.tar.zst with python-acme-2.7.2-1-any in .BUILDINFO.

The reason is that dependencies are resolved before the pkgver() function is called. Because the PKGBUILD contains "python-acme=$pkgver", python-acme=2.7.2-1 is fetched and installed. Then, pkgver() modified the $pkgver of the package to 2.7.4.
Comment by Toolybird (Toolybird) - Thursday, 16 November 2023, 01:59 GMT
So where is the bug, how do we fix it, and who do I assign this ticket to?

IIUC, there is no packaging issue here at all.. and this is some kind of tooling problem? If so, it needs to be tracked in the issue tracker for said tooling.. Which tool is at fault? Color me confused...
Comment by Iyan (iyanmv) - Thursday, 16 November 2023, 09:06 GMT
Well, this bug can be closed by simply repackaging all affected packages. A simple pkgrel bump will suffice since pkgver and _commit have the correct values now, and all these packages will be reproducible.

Regarding the tooling issue, I'm happy to open a different bug report to have a proper discussion. I think to prevent similar issues in the future, pkgctl should abort if pkgver is modified after dependencies have been fetched and .BUILDINFO has been generated.
Comment by Allan McRae (Allan) - Thursday, 16 November 2023, 10:19 GMT
This is a certbot packaging bug.

It uses the pkgver() to update the pkgver variable. But the dependencies get resolved before pkgver is updated. So dependencies such as "python-acme=$pkgver" can end up wrong.

Solutions:
1) always build twice
2) don't use pkgver()


Comment by Toolybird (Toolybird) - Thursday, 16 November 2023, 11:24 GMT
Thanks for the clarification @Allan.. it makes sense now. So basically a trap for young players...
Comment by Levente Polyak (anthraxx) - Thursday, 16 November 2023, 12:15 GMT
Seems the conclusion from my IRC explanation was misinterpreted as this is purely a packaging bug by violating a contract. If the packaging execution chain is broken down into abstract dependencies like "using a variable" and "changing a variable" etc, then it needs to be possible to represent this flow graph as an acyclic directed graph otherwise some expectation or contract is violated. using $pkgver in a dependency resolution variable which is needed to be run before the pkgver() function, which subsequently modifies the $pkgver variable creates an illegal cycle.

The conclusion is that the proposed solution 1 also doesn't really work: either the first run fails or the second run fails, but with the same input packages and without manually touching the $pkgver variable it is impossible to build twice (the dependency constraint is different).

IMO this leaves:
1) never use $pkgver in dependency resolution variables (*depends) if a pkgver function exists

PS: makepkg linting may want to warn or plain forbid this usage.
Comment by George Rawlinson (rawlinsong) - Thursday, 16 November 2023, 19:54 GMT
This is a bit disheartening because I make extensive use of the pkgver function; I rely on pinned commits to generate the pkgver because I’ve been bitten multiple times by various upstreams that think it’s acceptable to move git tags to a different commit.
Comment by Levente Polyak (anthraxx) - Thursday, 16 November 2023, 20:28 GMT
@George: Yeah, but fortunately the new pacman major version may arrive soon. Which will allow to hashsum git clones, which means you can have immutable git referenced by tag labels via the $pkgver variable rather than a hash. The immutability comes from the checksum array :)

Loading...