← Back to context

Comment by syllogism

7 months ago

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.

https://docs.npmjs.com/generating-provenance-statements

https://packaging.python.org/en/latest/specifications/index-...

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

      2 replies →

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)