Re: Git bomb still present (at least in SUSE)?

Re: Git bomb still present (at least in SUSE)?

[Jonathan Nieder]

(moving conversation to the main Git list.  I hope that's okay.)
Hi,

Jeff King wrote:
> On Tue, Jan 15, 2019 at 02:35:29PM +0100, Marketa Calabkova wrote:

>> meggy@irbis:/tmp/test> /usr/bin/time git clone
>> https://github.com/Katee/git-bomb.git
>> Cloning into 'git-bomb'...
>> remote: Enumerating objects: 18, done.
>> remote: Total 18 (delta 0), reused 0 (delta 0), pack-reused 18
>> Unpacking objects: 100% (18/18), done.
>> ^Cwarning: Clone succeeded, but checkout failed.
[...]
>   git clone --bare https://github.com/Katee/git-bomb.git
>   cd git-bomb.git
>   git read-tree HEAD ;# yikes!
>
> So I don't think there's a bug per se. It is possible that Git could
> have better protections against maliciously gigantic repositories, but I
> don't think anybody is actively working on such a feature (and it would
> involve much more than this case; it's pretty easy to generate trees
> with pessimal diffs, etc).

One thing I think interested people could do is introduce some kind of
"limits" subsystem into Git, so that a person could configure Git to
refuse to even try when it notices that an operation is going to be
sufficiently expensive.  I.e. something similar to what rlimits (or
other limits e.g. enforced in cgroups) provide in an operating system.

That said, as alluded to in the last paragraph, there's also some
protection possible at the operating system level.

So my feeling is that there's some real potential for improvement
here, and I'm happy to help mentor anyone working on it if it is their
itch (because of the "can handle at another level" thing, it is not
mine).

Thanks,
Jonathan

Re: Git bomb still present (at least in SUSE)?

[Marketa Calabkova]

[-- Attachment #1.1: Type: text/plain, Size: 2192 bytes --]

Hi,

Jonathan Nieder wrote:
> Jeff King wrote:
>> On Tue, Jan 15, 2019 at 02:35:29PM +0100, Marketa Calabkova wrote:
>>> meggy@irbis:/tmp/test> /usr/bin/time git clone
>>> https://github.com/Katee/git-bomb.git
>>> Cloning into 'git-bomb'...
>>> remote: Enumerating objects: 18, done.
>>> remote: Total 18 (delta 0), reused 0 (delta 0), pack-reused 18
>>> Unpacking objects: 100% (18/18), done.
>>> ^Cwarning: Clone succeeded, but checkout failed.
> [...]
>>   git clone --bare https://github.com/Katee/git-bomb.git
>>   cd git-bomb.git
>>   git read-tree HEAD ;# yikes!
>>
>> So I don't think there's a bug per se. It is possible that Git could
>> have better protections against maliciously gigantic repositories, but I
>> don't think anybody is actively working on such a feature (and it would
>> involve much more than this case; it's pretty easy to generate trees
>> with pessimal diffs, etc).
Thanks for your answer, now I finally understand what the fix is about.
> One thing I think interested people could do is introduce some kind of
> "limits" subsystem into Git, so that a person could configure Git to
> refuse to even try when it notices that an operation is going to be
> sufficiently expensive.  I.e. something similar to what rlimits (or
> other limits e.g. enforced in cgroups) provide in an operating system.
>
> That said, as alluded to in the last paragraph, there's also some
> protection possible at the operating system level.
>
> So my feeling is that there's some real potential for improvement
> here, and I'm happy to help mentor anyone working on it if it is their
> itch (because of the "can handle at another level" thing, it is not
> mine).
Thank you, I am interested. Mostly for educational purpose, I have to say,
I would like to contribute on such a big project as git is.

I would be happy if you help me with that. How can git know how big the
repository is before it tries to checkout? Or do you think it is OK to
start the operation, notice it is already too expensive and kill it? And,
well, how to easily track how expensive the operation is (e. g. not in the
particular operation)?

Greetings,
Marketa


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]