Re: Re: Merge with git-pasky II.
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Apr 16, 2005, 23:02 UTC
- Message-ID
- <Pine.LNX.4.62.0504161559140.22652@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <Pine.LNX.4.58.0504160913180.7211@ppc970.osdl.org>
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Show 22 quoted lines
> Almost all attacks on sha1 will depend on _replacing_ a file with a bogus > new one. So guys, instead of using sha256 or going overboard, just make > sure that when you synchronize, you NEVER import a file you already have. > > It's really that simple. Add "--ignore-existing" to your rsync scripts, > and you're pretty much done. That guarantees that a new evil blob by the > next mad scientist out to take over the world will never touch your > repository, and if we make this part of the _standard_ scripts, then > dammit, security is in good _practices_ rather than just relying blindly > on the hash being secure. > > In other words, I think we could have used md5's as the hash, if we just > make sure we have good practices. And it wouldn't have been "insecure". > > The fact is, you don't merge with people you don't trust. If you don't > trust them, they have a much easier time corrupting your repository by > just creating bugs in the code and checking that thing in. Who cares about > hash collisions, when you can generate a kernel root vulnerability by just > adding a single line of code and use the _correct_ hash for it. > > So the sha1 hash does not replace _trust_. That comes from something else > altogether.
What I am bringing up is not intended to be a trust thing, but instead a safety thing, accidents, not evil intent. makeing the rsync scripts --ignore-existing will avoid corrupting local data when pulling remotely, but it won't solve the problem of running into a collision locally (and won't do much to help you figure out what's wrong when you run into a remote collision)
David Lang
-- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare