Re: Performance issue: initial git clone causes massive repack

Nguyen Thai Ngoc Duy [off-list ref] writes:

quoted

2. Disallow initial clones over git:// (allow updates ONLY)

How can you do that? If I understand git protocol correctly, there is
no difference between a fetch request and a clone one.

At the protocol level, you can tell a clone request by noticing that the
downloading side does not have any "have" lines, but it is a different
matter what the software does out of the box.

You can patch upload-pack to reject such requests.  I am sure gentoo folks
are capable of doing that ;-)

Also a rogue client can send a bogus "have" to fool that logic, and that
is the primary reason why we do not have such a patch to upload-pack.  It
is not worth it as a protection against determined people who want to DoS.

On Tue, 14 Apr 2009, Junio C Hamano wrote:

Nguyen Thai Ngoc Duy [off-list ref] writes:

quoted

How can you do that? If I understand git protocol correctly, there is
no difference between a fetch request and a clone one.

At the protocol level, you can tell a clone request by noticing that the
downloading side does not have any "have" lines, but it is a different
matter what the software does out of the box.

You can patch upload-pack to reject such requests.  I am sure gentoo folks
are capable of doing that ;-)

Also a rogue client can send a bogus "have" to fool that logic, and that
is the primary reason why we do not have such a patch to upload-pack.  It
is not worth it as a protection against determined people who want to DoS.

Implementing a minimum treshold with merge-base to ensure that the 
client has at least commit X should be easy to do.  Unfortunately we 
don't have any hook for such a purpose yet.


Nicolas