3 ms·
I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's
by moonshinefe 10y ago
I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority):
1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems.
2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future.
3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files.
4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet.
Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.
- 5ilv3r 10y agoIf you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.