Re: git/git-scm.com GH Issue Tracker

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2017, 20:49 UTC
Message-ID: <xmqqlgtj11up.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170206184951.vwq6ib2qzxc542i4@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> [1] If we had a more permissive set of defaults, it would probably make
>     sense to turn on fsckObjects by default. Some of the checks are
>     security-relevant, like disallowing trees with ".GIT",
>     "../../etc/passwd", etc. Those _should_ be handled sanely by the
>     rest of Git, but it serves as a belt-and-suspenders check, and also
>     protects anybody with a buggy Git downstream from you.

Yeah, we really should encourage people to turn it on. Turning it on by default is one way to do so, of course.

I think the reason why the transfer side is stricter than the local checking [*1*] is because the problem in the local history is already done and there is not much the user can do to fix it, while objects that originate from outside world could be rejected to keep the receiving repository clean.

Show 11 quoted lines

>     GitHub has had the feature turned on for ages, with a few caveats:
>
>       - we loosened the zero-padded mode warning, because it was causing
> 	too many false positives
>
>       - we loosened the timezone checks for the same reason; we've seen
> 	time zones that aren't exactly 4 characters before
>
>       - we occasionally get complaints from people trying to push old
> 	histories with bogus committer idents. Usually a missing name or
> 	similar.

As long as we are sure that modern Git and its reimplementations no longer create objects with this problems, I think loosening these checks is perfectly sensible, as the only objects that trigger the check will be the ones buried deep in the history made back when Git was young.

Of course, that will make it easier to let broken objects created by newer reimplementations of Git (and bugs in our code that cause us to create such broken objects) go unnoticed, so we would want to keep them at warn (not ignore) for the end-users.

>      So those are the ones we'd probably need to loosen off the bat, and
>      they're all pretty harmless. But it would be a potential irritating
>      regression for somebody if they have a history with other minor
>      flaws, and Git suddenly starts refusing to clone it.

[Footnote]

*1* ... which is what Jonathan Nieder originally wondered at
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227