As you pointed out, signatures make content trusted, but only to the degree of the algorithm's attack resistance. I think it's also important to define trust; for our purposes this means: authenticity (the signer deliberately signed the input) and integrity (the input wasn't tampered with).
If an algorithm is collision resistant a signature guarantees both authenticity and integrity. If it's just second preimage resistant, signing may only guarantee authenticity.
Now, the issue with Git using SHA-1 is that an attacker may submit a new patch to a project, rather than attack an existing commit. In that case they are in control of both halves of the collision, and they just need for the benign half to be useful enough to get merged.
Any future commits with the file untouched would allow the attacker to swap it for their malicious half, while claiming integrity thanks to the maintainers' signatures. They could do this by either breaching the official server or setting up a mirror.
One interesting thing to note though: in the case of human readable input such as source code, this attack breaks down as soon as you verify the repo contents. Therefore it's only feasible longer term when using binary or obfuscated formats.
How exactly do you think they started to suck? Also, what’s stopping platforms from servicing large numbers of users? Honest questions, I’m just curious.
It's always sad to see someone get burnt by the internet, I wish him, and also those who criticised him, well.
On a brighter note, I appreciate the noob-friendly explanations. It made it really easy to follow along.
I'm also really curious about how Java achieves better stdout performance. I hope we get to apply the lessons to other environments too! I didn't read all of it, so perhaps there's a clue in @bugaevc's PR[1] mentioned in the article.
[1] did in fact talk about and link to a Rust discussion PR[2] about the stdout perf issue. Essentially Rust always flushes stdout for every line of output, whereas other languages like Python tend to buffer larger blocks before flushing.
If an algorithm is collision resistant a signature guarantees both authenticity and integrity. If it's just second preimage resistant, signing may only guarantee authenticity.
Now, the issue with Git using SHA-1 is that an attacker may submit a new patch to a project, rather than attack an existing commit. In that case they are in control of both halves of the collision, and they just need for the benign half to be useful enough to get merged.
Any future commits with the file untouched would allow the attacker to swap it for their malicious half, while claiming integrity thanks to the maintainers' signatures. They could do this by either breaching the official server or setting up a mirror.
One interesting thing to note though: in the case of human readable input such as source code, this attack breaks down as soon as you verify the repo contents. Therefore it's only feasible longer term when using binary or obfuscated formats.