* warning in tree xxx: contains zero-padded file modes
@ 2017-02-06 20:23 Samuel Lijin
2017-02-06 20:26 ` Samuel Lijin
2017-02-06 20:32 ` Jeff King
0 siblings, 2 replies; 3+ messages in thread
From: Samuel Lijin @ 2017-02-06 20:23 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, git@vger.kernel.org
I'm just going to go ahead and split this off the git/git-scm.com
issues thread since this is a distinct topic.
On Mon, Feb 6, 2017 at 12:49 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
>
>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>> > # Irrelevant but someone should take a look
>> >
>> > 693
>>
>> To save people some time (and since i looked at it anyway), this is
>> about whether "warning in tree xxx: contains zero-padded file modes:
>> from fsck should be a warning or error. It is a warning now even
>> though "git -c transfer.fsckobjects=true clone" treats it as an error.
>> There are some discussions in the past [1] [2] about this.
I think you forgot to link to [2] :p
> The bug that caused the trees is long-fixed. There's a question of
> how severity levels should be handled in transfer.fsckObjects. By
> default it treats everything as a reason to reject the object. Dscho
> added configurable levels a few versions ago. It may be a good idea to
> tweak the defaults to something more permissive[1].
>
>> There's also a question "And I failed to find in the documentation if
>> transfer.fsckobjects could be disabled per repository, can you confirm
>> it's not possible for now ?"
>
> I don't know why it wouldn't be, though note that it won't override
> the operation-specific {receive,fetch}.fsckObjects.
>
> -Peff
>
> [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.
>
> 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.
>
> 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.
The linked issue on bugs.debian.org has seen activity recently, which
is the main reason I mentioned it separately as still relevant:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: warning in tree xxx: contains zero-padded file modes
2017-02-06 20:23 warning in tree xxx: contains zero-padded file modes Samuel Lijin
@ 2017-02-06 20:26 ` Samuel Lijin
2017-02-06 20:32 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Samuel Lijin @ 2017-02-06 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, git@vger.kernel.org
On Mon, Feb 6, 2017 at 2:23 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> I'm just going to go ahead and split this off the git/git-scm.com
> issues thread since this is a distinct topic.
>
> On Mon, Feb 6, 2017 at 12:49 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
>>
>>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>> > # Irrelevant but someone should take a look
>>> >
>>> > 693
>>>
>>> To save people some time (and since i looked at it anyway), this is
>>> about whether "warning in tree xxx: contains zero-padded file modes:
>>> from fsck should be a warning or error. It is a warning now even
>>> though "git -c transfer.fsckobjects=true clone" treats it as an error.
>>> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
>
>> The bug that caused the trees is long-fixed. There's a question of
>> how severity levels should be handled in transfer.fsckObjects. By
>> default it treats everything as a reason to reject the object. Dscho
>> added configurable levels a few versions ago. It may be a good idea to
>> tweak the defaults to something more permissive[1].
>>
>>> There's also a question "And I failed to find in the documentation if
>>> transfer.fsckobjects could be disabled per repository, can you confirm
>>> it's not possible for now ?"
>>
>> I don't know why it wouldn't be, though note that it won't override
>> the operation-specific {receive,fetch}.fsckObjects.
>>
>> -Peff
>>
>> [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.
>>
>> 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.
>>
>> 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.
>
> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
I take it back: last activity was in Feb 2016. >_<
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: warning in tree xxx: contains zero-padded file modes
2017-02-06 20:23 warning in tree xxx: contains zero-padded file modes Samuel Lijin
2017-02-06 20:26 ` Samuel Lijin
@ 2017-02-06 20:32 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Jeff King @ 2017-02-06 20:32 UTC (permalink / raw)
To: Samuel Lijin; +Cc: Duy Nguyen, git@vger.kernel.org
On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote:
> >> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
I think the [1] [2] there were recursive quotes from Duy's email. Those
footnotes were:
[1] http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com%3E/
[2] http://public-inbox.org/git/%3C20100326215600.GA10910@spearce.org%3E/
> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227
Yeah. I think that's not quite solvable with Git as we have it now. We
have fsck.* and receive.fsck.* to tweak severity levels, but no matching
fetch.fsck.* for handling a push (and presumably a transfer.fsck.* to
cover both fetching and pushing). So there's a potential patch series
for anybody interested.
-Peff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-06 20:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-06 20:23 warning in tree xxx: contains zero-padded file modes Samuel Lijin
2017-02-06 20:26 ` Samuel Lijin
2017-02-06 20:32 ` Jeff King
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).