Re: git-index-pack really does suck..

From: Nicolas Pitre <nico@cam.org>
Date: Apr 3, 2007, 22:55 UTC
Message-ID: <alpine.LFD.0.98.0704031836350.28181@xanadu.home>
In-Reply-To: <Pine.LNX.4.64.0704031511580.6730@woody.linux-foundation.org>

On Tue, 3 Apr 2007, Linus Torvalds wrote:

Show 6 quoted lines

> I don't care *what* it is conditional on, but your arguments suck. You 
> claim that it's not a normal case to already have the objects, when it 
> *is* a normal case for alternates, etc.
> 
> I don't understand why you argue against hard numbers. You have none of 
> your own.

Are hard numbers like 7% overhead (because right now that's all we have) really worth it against bad _perceptions_?

Sure, the SHA1 collision attack is paranoia. But it is becoming increasingly *possible*.

And when we only had unpack-objects on the receiving end of a fetch, you yourself bragged about the implied security of GIT in the presence of a SHA1 collision attack. Because let's admit it: when a SHA1 collision will happen it is way more probable to come on purpose than from pure accident. But as you said at the time, it is not a problem because GIT trusts local objects more than remote ones and incidentally unpack-objects doesn't overwrite existing objects.

The keeping of fetched packs broke that presumption of trust towards local objects and it opened a real path for potential future attacks. Those attacks are still fairly theoretical of course. But for how _long_? Do we want GIT to be considered backdoor prone in a couple years from now just because we were obsessed by a 7% CPU overhead?

I think we have much more to gain by playing it safe and being more secure and paranoid than trying to squeeze some CPU cycles out of an operation that is likely to ever be bounded by network speed for most people.

And we _know_ that the operation can be optimized further anyway.

So IMHO in this case hard numbers alone aren't the end of it. Not as long as they're reasonably low. And especially not for a command which is 1) rather infrequent and 2) not really interactive like git-log might be.

Nicolas