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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 13.05.2011 18:54, schrieb Johan Herland:
> There's something weird going on here: The included test case works as
> intended, but when I try to test this in "real-world" conditions,
> I don't get the expected error message in the output:
> 
>   # From inside my git.git repo:
>   $ git init --bare foo.git
>   $ (cd foo.git && git config receive.denyObjectLimit 100000)
>   $ git push foo.git/ master
>   Pushing to foo.git/
>   Counting objects: 112383, done.
>   Delta compression using up to 8 threads.
>   Compressing objects: 100% (27658/27658), done.
>   error: pack-objects died of signal 13
>   error: failed to push some refs to 'foo.git/'
>   $
> 
> So the pack-objects on the local side dies of a broken pipe (as
> expected), but the error message from the remote side:
> 
>   error: unpack failed: received pack exceeds configured receive.denyObjectLimit
> 
> is never printed, so the user gets no clue as to why the push failed.

The error message is printed by receive_status(), called around line 350
in builtin/send-pack.c. But when pack-object fails, then the
pack_objects() call around line 340 signals an error and an early-exit
branch is taken, and receive_status() is never called.

In the test case, only a small amount of data is produced by
pack-objects, so that it can exit successfully and quickly enough
because the data fits into the pipe buffer. If the pack-objects process
were scheduled differently, there is a chance that it dies from SIGPIPE
as well. So, you are just being lucky that the test case succeeds.

-- Hannes
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]