Maintainers need to keep a wall between the package publishing and public repos. Currently what people are doing is configuring the public repo as a Trusted Publisher directly. This means you can trigger the package publication from the repo itself, and the public repo is a huge surface area.
Configure the CI to make a release with the artefacts attached. Then have an entirely private repo that can't be triggered automatically as the publisher. The publisher repo fetches the artefacts and does the pypi/npm/whatever release.
The point of trusted publishing is supposed to be that the public can verifiably audit the exact source from which the published artifacts were generated. Breaking that chain via a private repo is a step backwards.
Pardon my limited understanding but my read of the suggestion was simply to perform the same exact operation that the public would do to verifiably audit the exact source when generating the official published artifacts, the point was just that there was no automation to do so directly from the public repo.
The maintainer can verify the correspondence between source and release, but the public has been deprived of this verifiability.
This matters. Consider the XZ Utils compromise where a malicious maintainer hid the line that triggers compilation of the (otherwise dormant) backdoor payload in a generated file present only in the release tarball: https://www.openwall.com/lists/oss-security/2024/03/29/4. If the public had the ability to audit that the release tarball was correctly built from the version-controlled code, this would have been much more difficult to hide.
I interpret your comment as emphasizing that the current norm relying on publicly accessible (GitHub) infrastructure building releases in public and thus allowing public review of logs and artifacts provides tremendous value (and I admit that true 100% binary reproducibility is an often nearly unreachable goal still not yet typically expected as the norm).
> Breaking that chain via a private repo is a step backwards
I was stating that performing a reproducible build elsewhere and distributing the output could in theory still be validated though it would require re-running said build for one's self and comparing the outputs. This might encourage the pursuit of 100% reproducibility! The chain need not be considered broken just because the final link is private.
> the public has been deprived of this verifiability
This is not what I was trying to point out, though I agree the cost of verifying reproducibility would be higher. My point was that anyone could still perform the same steps themselves and verify the output. Yes this would be more work than reviewing logs on GitHub.
OP's primary concern with today's standard approach appears to be the automated connection from GitHub build action -> release. Even simply requiring manual maintainer intervention to copy the action output over to a release seems to satisfy both their and your concerns.
> If the public had the ability to audit that the release tarball was correctly built from the version-controlled code
I am not intimately familiar with all the details of the XZ fiasco but agree that it offers an opportunity to learn and make changes to work toward making sure nothing similar can happen to any project again. If I am reading your link correctly, it serves as an example of members of the public (not a maintainer of XZ) doing exactly what you said: auditing the release tarball. IIRC this occurred only after an additional point release (apparently allowing the attacker to fix a bug in their backdoor) because of a performance regression.
Right, the public was able to spend manual effort hand-auditing one specific tarball after it had already been singled out as suspicious for other reasons. In order for verification to effectively increase supply chain security, it needs to become uniformly standardized, fully automated, and ubiquitous. That’s the ultimate goal of the provenance attestation mechanisms that would be defeated by indirection through private repositories.
If you want to require extra maintainer intervention for releases, there are better mechanisms available for that, such as workflow_dispatch.
this kind of compromise is why a lot of orgs have internal mirrors of repos or package sources so they can stay behind few versions to avoid latest and compromise. seen it with internal pip repos, apt repos etc.
some will even audit each package in there (kind crap job but it works fairly well as mitigation)
Configure the CI to make a release with the artefacts attached. Then have an entirely private repo that can't be triggered automatically as the publisher. The publisher repo fetches the artefacts and does the pypi/npm/whatever release.