Hacker News Reader

Comment by g-b-r | Hacker News Reader

GitHub release builds provide no whatsoever guarantee of having been built by GitHub from the corresponding source, if I remember correctly

View on HN

Ah, I think you might be pleasantly surprised that this is an area being focused on right now with attestations[1] for example, here are the attestations for the GitHub CLI[2].

1: https://github.blog/2024-05-02-introducing-artifact-attestat...

2: https://github.com/cli/cli/attestations

Maybe this whole cryptographic stuff has some use, but all that which was needed was for GitHub to declare when a file was uploaded manually and when by a workflow (specifying which workflow).

This looks so complex that it might well be just smoke and mirrors

So the worry is the Zed team themselves will inject something into the binary?

The xz backdoor was an example of exploiting this disconnect. It was not present in the repository, it was inserted only into the release artifacts. Anyone getting xz by checking out the repository and building it themselves, would not be affected by it.

I think that's a slight mischaracterization. It was present in the repo but obfuscated and rigged to only apply in release artifacts.

A sufficiently technical user could have found it but that bar was pretty high to clear.

I'm pretty sure that's incorrect. One portion of the build-to-host buildfile was only present in the release tarball.

https://www.openwall.com/lists/oss-security/2024/03/29/4

Right but it was injected from data in a "corrupt" xz file in the repo under certain conditions

>This injects an obfuscated script to be executed at the end of configure. This script is fairly obfuscated and data from "test" .xz files in the repository.

>The files containing the bulk of the exploit are in an obfuscated form in tests/files/bad-3-corrupt_lzma2.xz tests/files/good-large_compressed.lzma committed upstream

Reply on news.ycombinator.com