On Tue, Mar 3, 2015 at 9:13 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> Junio pointed out in private that I didn't address the packet length >> limit (64k). I thought I could get away with a new capability >> (i.e. not worry about it now) but I finally admit that was a bad >> hack. So perhaps this on top. > > No, I didn't ;-) but I tend to agree that "perhaps 4GB huge packet?" > is a bad idea. > > The problem I had with the version in your write-up was that it > still assumed that all capabilities must come on one packet-line. > So I started looking into extending the buffer size as another 'first step' towards the protocol version 2 again. But now I think the packed length limit of 64k is actually a good and useful thing to have and should be extended/fixed if and only if we run into serious trouble with too small packets later. I mean we can add the possibility now by introducing these special length 0xFFFF or 0xFFFE to mean we'd want to extend it in the future. But when doing this we need to be extra careful with buffer allocation. As it is easy to produce a denial of service attack if the receiving side blindly trusts the length and allocates as much memory. So having a 64k limit actually helps preventing this attack a bit as it is a very small number. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html