# warning in tree xxx: contains zero-padded file modes 3 messages from 2017-02-06 to 2017-02-06. Participants: Samuel Lijin, Jeff King. Thread: https://gitlist.dev/t/45062 ## Samuel Lijin, 2017-02-06 20:23 Subject: warning in tree xxx: contains zero-padded file modes Message-ID: URL: https://gitlist.dev/e/CAJZjrdWq%2BxSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM%3Dg%40mail.gmail.com ``` 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 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 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 ``` ## Samuel Lijin, 2017-02-06 20:26 Subject: Re: warning in tree xxx: contains zero-padded file modes Message-ID: URL: https://gitlist.dev/e/CAJZjrdUdQ4JMTG9sciP3N_qQ4OgB-o%2Bf-G%3DooDikwpgasFnEXg%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 6, 2017 at 2:23 PM, Samuel Lijin 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 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 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. >_< ``` ## Jeff King, 2017-02-06 20:32 Subject: Re: warning in tree xxx: contains zero-padded file modes Message-ID: <20170206203214.5y6ynn5co7davtrj@sigill.intra.peff.net> URL: https://gitlist.dev/e/20170206203214.5y6ynn5co7davtrj%40sigill.intra.peff.net In-Reply-To: ``` 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 ```