A better summary. [LWN.net]

A better summary.

Posted Jun 10, 2026 17:45 UTC (Wed) by mathstuf (subscriber, #69389)
In reply to: A better summary. by alx.manpages
Parent article: Eliminating long-lived credentials with trusted publishing

How is that build server going to make an environment suitable for building your project available? Arbitrary Docker images is probably the solution, but that is just moving the problem under a different rug. I know you tend to work on lower-level utilities, but there are projects that have dozens of dependencies that may not be reproducible themselves. Not to mention you're limited in the set of platforms supported by that build service. Also that reproducibility is a per-target property and not determinate a priori a lot of time.

A "I have a reproducible build and only really care about Linux (x86_64, maybe aarch64 too)" might be a fine alternate trusted publisher of binary artifacts given a GPG-signed tarball like you have, but I suspect its use would be by a tiny portion of projects.

to post comments

A better summary.

Posted Jun 10, 2026 19:36 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

If Debian can be reproducible, i suspect that most .py and .js projects can be as well.

Github actions are a mess. Builds should run without network access as a minimum condition. And PyPI should probably require projects to be able to build.

That's not what happens at all.

I agree that a long lived token sitting on a developer's machine can be compromised.

However it can happen to their ssh keys too. But we wouldn't necessarily care if the github action to build a package was standardised and ran without network access at the very least.

We are defending against a very minor attack and ignoring all the rest. If this wasn't in the threat modelling… perhaps the threat modelling was bad as well?