Re: [PATCHv2 2/2] receive-pack: Add receive.objectCountLimit to refuse push with too many objects

[Johan Herland <johan@herland.net>]

On Saturday 14 May 2011, Shawn Pearce wrote:
> I wonder... should we instead export the objectCountLimit as part of
> the advertisement to the client, and teach send-pack to look at this
> and pass it down to pack-objects? If pack-objects winds up with more
> than this limit, it aborts and the client doesn't even transmit data.
> Newer clients would abort cleanly with a nice error.

Good idea (although it grows the scope from the quick-fix I initially 
intended it to be...)

I'm planning to add a new capability collection/namespace, called "limit-*", 
where the server can communicate capabilities to the client, like so:

  limit-object-count_100000
  limit-commit-count_1000
  limit-pack-size_500000000

(I'd prefer to s/_/=/ or s/_/:/, but according to pack-protocol.txt, a 
capability may not contain "=" or ":")

However, you say:

> For older clients that don't know this new advertised capability, they
> should fail hard and not transfer all of this data.

AFAICS this is not the case. If a client does not understand a capability, 
it simply ignores it, and carries on doing its usual thing.

IINM there are only two ways to prevent an older client from transferring 
all the data:

1. Change the pack protocol in an incompatible way, that causes older client 
to abort with a pack format error prior to transmitting the pack.

2. (as in initial patch) Abort receive-pack when the server detects a limit 
violation, leaving the client with a broken pipe. I haven't read the pack 
protocol closely, but I wouldn't be surprised if this behavior is strictly 
in violation of the protocol.

> In my experience
> when a user gets these strange errors from his Git client, he contacts
> his server administrator with the screen output. At which point the
> administrator can see the Counting objects line, check the repository
> configuration, and tell the user what the problem is... and encourage
> them to upgrade their client to a newer version.

Hmm... Not ideal, but I guess we can live with that. At least we should warn 
the server administrator of this in the documentation of the config 
variable(s).


Otherwise, I agree with everything you wrote.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net