4 ms·

You're saying Linus's statements are "hugely misleading", but it's just that you wish git were designed to be used differently. So, your argument is "horseshit"

• paulddraper 10y ago
  > Before git, we all used CVS, SVN, tarballs, and patches Yeah, and that sucked. Git is this close (I'm holding my fingers very close together) from providing cryptographic proof of source history. And that's why people think it should be included.
• infinity0 10y ago
  Why go through all the effort of securing kernel.org etc etc etc when a simple s/SHA1/SHA512/g on git would suffice? (Ignoring the non-git infrastructure there, for the purposes of this argument.) Not just for him, but for everyone in the world who can't download directly from kernel.org? What's the point of GPG signing tags and commits and adding these as git features, when SHA1 pointers make it pointless? If the cryptographic strength of the hash doesn't matter, why bother even talking about changing the hash from SHA1 to SHA3-256? It's a huge shame because git is very close to being a cryptographically perfect system, but the original creator can't get his security reasoning correct, and does so so badly yet so publicly, and minions who don't know what they're talking about come flocking to defend this.
  • kupiakos 10y ago
    > when a simple s/SHA1/SHA512/g on git would suffice? That's ignoring a huge amount of changes that have to be made to have this work properly. Hardcoded constants must be changed. Backwards compatibility needs to be maintained for Git to be a viable product. Scripts that depend on the current length/format of SHA1 hashes would be broken if everything were changed all of a sudden. That would be much, much worse than the current exploit. I agree that his points are not all correct, but he is correct in that basically, you shouldn't have all of your security eggs in one basket. SHA1 is just one piece of their security infrastructure, and now that it's shown to be a little shaky, it can be argued that the others help keep it up while they repair it. SHA1 pointers being "pointless" is also an overstatement. SHA1 isn't completely broken yet. It will be pointless in 3+ years, which is why they're performing the work of transitioning, although not easy. "Cryptographically perfect" wouldn't be occurring with SHA3-256 either. That'll be broken in 10+ years. Security is, and always has been, along the lines of "good enough as far as we can see now", and when Git was made, it was good enough. Now it's not.
    • infinity0 10y ago
      All git repos have "repositoryversionformat", you can bump it. And nobody is going to complain about having to do a fresh clone, given what just happened. "Not having security eggs in one basket" is exactly irrelevant here. Upgrading the hash does not make the other parts of the system weaker, and should have been done years ago. Yes, SHA2 will also become weak eventually - so then you bump it again. The point is to choose the best one for that time of history, which he has been resisting doing for years, based on bullshit pseudo-arguments about "trust". No, git uses hashes in the same way that most other security system use hashes. The "trust" comes at a different point of the system. No hashes by themselves are "trusted" anywhere by any system. Git is not special in this regard. I repeat, Linus is talking horseshit and this horsehit argument is unfortunately getting repeated and spread around because of his position in the community. I said the use of GPG is pointless, not SHA1 pointers, especially given his "trust" arguments. To exaggerate slightly, just to show you the point: it's like locking up a crappy lock (SHA1) inside a really secure safe (GPG). But this crappy lock is what opens up the real safe where your actual money is kept (the tree objects). And then we have Linus talking shit on the side saying the keys are not so important, but what he really gets security from is his trust in the delivery company that ships the safe around.
• kpcyrd 10y ago
  > How could any of us have trusted any source code before 2005?! Somehow we did, though... They used pgp to sign the tar ball, which was a way better idea since you could just use a different hash function for your signature after sha1 has been broken in 2005[1]. Everybody serious about security kept doing that, since signed git commits were just asking for trouble due to the hard dependency on sha1. [1]: https://www.schneier.com/blog/archives/2005/02/sha1_broken.html https://www.schneier.com/blog/archives/2005/02/sha1_broken.h...
• DannyBee 10y ago
  "Finally, no well-known SCM previous to git was based on perfect cryptographic proof of source history, or anything like that." This is actually false. Monotone, from which git takes a lot of cues (ask linus, or see wikipedia), was such a system.
  • ploxiln 10y ago
    Thus my qualification "well known". I was aware of monotone and Darcs ... but never used them, or knew anyone who did, or anyone who seriously considered it. I have no idea if Darcs is "cryptographically secure". But both of these were experimental and extremely slow at the time git was designed.
    • DannyBee 10y ago
      "Thus my qualification "well known"." So that, to you, means "i don't know anyone who used them"? Because that's a pretty small definition of "well known". For reference: Inside the VCS community, they were very well known. Graydon also went on to start Rust, of course. Outside of that, even to corporations I dealt with (i was working on SVN at the time), plenty knew it existed, a few evaluated it. " But both of these were experimental and extremely slow at the time git was designed." I feel like this is just you trying to say "well, they never would have worked anyway". DARCS was slow and couldn't be fixed, monotone was actually not that bad, and could be made very fast if necessary. Monotone was slow precisely because it cared about integrity. If you made git care about integrity and security in the same way ... it would be just as slow! Saying they were "experimental" is silly. Monotone was self hosting and nobody had found data corruption or other issues in quite a while (IE > 1 year), AFAIK. This is much better than git was for a long time. To put this in perspective, i converted the gcc repository (hundreds of thousands of revisions, in fact, many more than the kernel at the time, and history going back to 1983) to monotone, and 1. the conversion worked with no issues 2. Speed was fine in most cases. If i worked hard, i could find issues, but .... git was beyond experimental at the time it was designed (IE data loss and repeated crashes). But it's design is essentially that of monotone in a different container and with slightly different goals. (IE they precisely gave up the integrity part that monotone verified and cared about, and people are now complaining about). In truth, if Linus had cared about cryptographic security, he probably would have just stuck with monotone and rewritten parts of it. But he didn't, so he gave that up in the name of speed. Which is fine, but let's not pretend that Linus somehow has a monopoly on design, or even was the first to design a VCS that was like git. Any of the distributed VCSen could have beaten git. They just didn't care about the tradeoffs that git was making (IE non-portability in favor of speed), and honestly, it's pretty obvious git would have been laughed out of existence if it hadn't been supported by someone so popular to so many people. In fact, it was laughed out of existence, the past N times people had devised VCSen that favored speed over portability. Git is interesting as an example of how good marketing with the right figures sometimes leads to winning in the marketplace for long enough that you can fix the rest of your serious issues (IE everyone else had the OS/2 problem). Even more interesting is that everyone else backfills history to make it seem like it was the best and clearly the right set of tradeoffs from the start. It wasn't. It may not even be now! It's like any other system. Please don't try to backfill history here. I was there, as were many others.