git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

From
Christian Couder <christian.couder@gmail.com>
Date
Aug 16, 2016, 08:25 UTC
Message-ID
<CAP8UFD2Bpp-gcxEQGNSFxvKyptkyeAsMtaHZaBebJO2XiF+W3g@mail.gmail.com>
In-Reply-To
<20160816010309.zstrljqknc3vjziq@sigill.intra.peff.net>
On Tue, Aug 16, 2016 at 3:03 AM, Jeff King <peff@peff.net> wrote:
Show 20 quoted lines
> On Mon, Aug 15, 2016 at 03:48:55PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > The simple fix is to call register_tempfile() in open_pack_file(), and
>> > just have index-pack clean up the file on its way out.
>> >
>> > But there are harder cases. For instance, imagine somebody pushes a
>> > 500MB file, and you have a pre-receive hook that says "too big; I won't
>> > accept this". And then they push in a loop, as before. You've accepted
>> > the incoming pack into the repository by the time the pre-receive runs.
>> > You can't just delete it, because you don't know if other simultaneous
>> > processes have started to depend on the objects.
>> >
>> > To solve that, I have patches that put incoming packfiles into a
>> > "quarantine" area, then run the connectivity check and pre-receive hooks
>> > with the quarantine accessible via GIT_ALTERNATE_OBJECT_DIRECTORIES. And
>> > then we either move the quarantine packs into the real repo, or blow
>> > away the tmpdir, depending on whether the hooks said the objects were
>> > OK.
Thanks Peff for the review and all these explanations and suggestions!
>> > Those are patches I plan to share upstream but just haven't gotten
>> > around to yet.
I would be happy to help if I can on these patches too!
>> I think these other patches can come later, independent from this
>> three-patch series resurrected from the archive, so I can take a
>> reroll of these once the integer-size issues you pointed out are
>> sorted out.

Ok, I just sent a non RFC reroll of the series with those issues hopefully fixed.

> Yeah, definitely it's independent. I was mostly suggesting to Christian
> that he may want to look into the "easy" register_tempfile() case, as
> GitLab may find this is only half of the fix that they want.
Yeah, thanks again for this suggestion!
> Also a patch I may try to polish and share in the future, but not as
> high priority as some of the other stuff.
I can help polishing this patch if you want.

Thanks, Christian.

Previous: Jeff KingNext: Jeff King
Message 10 of 11 in “limit the size of the packs we receive”
  1. 0/3 limit the size of the packs we receiveChristian Couder, Aug 15, 2016
  2. 1/3 index-pack: add --max-input-size=<size> optionChristian Couder, Aug 15, 2016
  3. Jeff KingAug 15, 2016
  4. 2/3 unpack-objects: add --max-input-size=<size> optionChristian Couder, Aug 15, 2016
  5. Jeff KingAug 15, 2016
  6. 3/3 receive-pack: allow a maximum input size to be specifiedChristian Couder, Aug 15, 2016
  7. Jeff KingAug 15, 2016
  8. Junio C HamanoAug 15, 2016
  9. Jeff KingAug 16, 2016
  10. Christian CouderAug 16, 2016
  11. Jeff KingAug 16, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.