Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Could you explain why you think it is a likely risk? Has this attack happened frequently?


It is likely in the same way that aliens are statistically likely. There is no evidence so far afaik, but you will likely never find out when it happens, and it can compromise the whole world if it were to happen to a widely used package. It is not worth the risk to not have the feature. I even think it should ideally eventually become mandatory.


If it happens, you won’t notice it even with PEP740 because all those “trusted publishers” already are or may easily be compromised by state actors. It’s all smoke and mirrors without reproducible builds.


Yes. Solarwinds.

Code checked out from the repository was not the same that was used to build the actual release. These are not high-likelyhood incidents but when they do occur, they tend to have high impact.

And more recently, semantically similar code-vs-build mismatch: CrowdStrike. The broken release was modified after the actual build step, as per their own build process, and the modified artifact is what was released.


To which CrowdStrike incident are you refering to? The global impact CrowdStrike incident was caused due to a driver defect which wasn't caught by quality assurance processes. It had nothing to do with malicious actors which were interfering with the code repository or the software deploment process.


The same incident, because the root causes are even more messed up than just shoddy QA.

Yes, the thing wasn't caught because of missing QA. What I find even worse is that the build process for their "channel files" involved:

    * building a release in CI, for which tests were run
    * modifying the built artifact as a post-process step, and
    * uploading this modified end result into their CDN infrastructure
In effect, what they actually built from their sources in the CI pipeline was not what was delivered to end users. You are correct in that attestations wouldn't help against such flagrant lies. And it wasn't a malicious act (although maliciously incompetent might qualify).

That post-build modification step would fly in the face of the attestation concept. It wouldn't help against having an empty set of tests, but an attestation-friendly build process at least would discourage messing around with the artifacts prior to release.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: