{"thread":{"id":"45062","subject":"warning in tree xxx: contains zero-padded file modes","startedAt":"2017-02-06T20:24:25Z","lastAt":"2017-02-06T20:32:23Z","messageCount":3,"participants":["Samuel Lijin","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310939","messageId":"CAJZjrdWq+xSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM=g@mail.gmail.com","threadId":"45062","inReplyTo":null,"subject":"warning in tree xxx: contains zero-padded file modes","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-06T20:23:37Z","receivedAt":"2017-02-06T20:24:25Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"I'm just going to go ahead and split this off the git/git-scm.com\nissues thread since this is a distinct topic.\n\nOn Mon, Feb 6, 2017 at 12:49 PM, Jeff King wrote:\n> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:\n>\n>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin wrote:\n>> > # Irrelevant but someone should take a look\n>> >\n>> > 693\n>>\n>> To save people some time (and since i looked at it anyway), this is\n>> about whether \"warning in tree xxx: contains zero-padded file modes:\n>> from fsck should be a warning or error. It is a warning now even\n>> though \"git -c transfer.fsckobjects=true clone\" treats it as an error.\n>> There are some discussions in the past [1] [2] about this.\n\nI think you forgot to link to [2] :p\n\n> The bug that caused the trees is long-fixed. There's a question of\n> how severity levels should be handled in transfer.fsckObjects. By\n> default it treats everything as a reason to reject the object. Dscho\n> added configurable levels a few versions ago. It may be a good idea to\n> tweak the defaults to something more permissive[1].\n>\n>> There's also a question \"And I failed to find in the documentation if\n>> transfer.fsckobjects could be disabled per repository, can you confirm\n>> it's not possible for now ?\"\n>\n> I don't know why it wouldn't be, though note that it won't override\n> the operation-specific {receive,fetch}.fsckObjects.\n>\n> -Peff\n>\n> [1] If we had a more permissive set of defaults, it would probably make\n> sense to turn on fsckObjects by default. Some of the checks are\n> security-relevant, like disallowing trees with \".GIT\",\n> \"../../etc/passwd\", etc. Those _should_ be handled sanely by the\n> rest of Git, but it serves as a belt-and-suspenders check, and also\n> protects anybody with a buggy Git downstream from you.\n>\n> GitHub has had the feature turned on for ages, with a few caveats:\n>\n> - we loosened the zero-padded mode warning, because it was causing\n> too many false positives\n>\n> - we loosened the timezone checks for the same reason; we've seen\n> time zones that aren't exactly 4 characters before\n>\n> - we occasionally get complaints from people trying to push old\n> histories with bogus committer idents. Usually a missing name or\n> similar.\n>\n> So those are the ones we'd probably need to loosen off the bat, and\n> they're all pretty harmless. But it would be a potential irritating\n> regression for somebody if they have a history with other minor\n> flaws, and Git suddenly starts refusing to clone it.\n\nThe linked issue on bugs.debian.org has seen activity recently, which\nis the main reason I mentioned it separately as still relevant:\nhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227\n"},{"id":"310940","messageId":"CAJZjrdUdQ4JMTG9sciP3N_qQ4OgB-o+f-G=ooDikwpgasFnEXg@mail.gmail.com","threadId":"45062","inReplyTo":"CAJZjrdWq+xSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM=g@mail.gmail.com","subject":"Re: warning in tree xxx: contains zero-padded file modes","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-02-06T20:26:42Z","receivedAt":"2017-02-06T20:28:41Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Mon, Feb 6, 2017 at 2:23 PM, Samuel Lijin wrote:\n> I'm just going to go ahead and split this off the git/git-scm.com\n> issues thread since this is a distinct topic.\n>\n> On Mon, Feb 6, 2017 at 12:49 PM, Jeff King wrote:\n>> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:\n>>\n>>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin wrote:\n>>> > # Irrelevant but someone should take a look\n>>> >\n>>> > 693\n>>>\n>>> To save people some time (and since i looked at it anyway), this is\n>>> about whether \"warning in tree xxx: contains zero-padded file modes:\n>>> from fsck should be a warning or error. It is a warning now even\n>>> though \"git -c transfer.fsckobjects=true clone\" treats it as an error.\n>>> There are some discussions in the past [1] [2] about this.\n>\n> I think you forgot to link to [2] :p\n>\n>> The bug that caused the trees is long-fixed. There's a question of\n>> how severity levels should be handled in transfer.fsckObjects. By\n>> default it treats everything as a reason to reject the object. Dscho\n>> added configurable levels a few versions ago. It may be a good idea to\n>> tweak the defaults to something more permissive[1].\n>>\n>>> There's also a question \"And I failed to find in the documentation if\n>>> transfer.fsckobjects could be disabled per repository, can you confirm\n>>> it's not possible for now ?\"\n>>\n>> I don't know why it wouldn't be, though note that it won't override\n>> the operation-specific {receive,fetch}.fsckObjects.\n>>\n>> -Peff\n>>\n>> [1] If we had a more permissive set of defaults, it would probably make\n>> sense to turn on fsckObjects by default. Some of the checks are\n>> security-relevant, like disallowing trees with \".GIT\",\n>> \"../../etc/passwd\", etc. Those _should_ be handled sanely by the\n>> rest of Git, but it serves as a belt-and-suspenders check, and also\n>> protects anybody with a buggy Git downstream from you.\n>>\n>> GitHub has had the feature turned on for ages, with a few caveats:\n>>\n>> - we loosened the zero-padded mode warning, because it was causing\n>> too many false positives\n>>\n>> - we loosened the timezone checks for the same reason; we've seen\n>> time zones that aren't exactly 4 characters before\n>>\n>> - we occasionally get complaints from people trying to push old\n>> histories with bogus committer idents. Usually a missing name or\n>> similar.\n>>\n>> So those are the ones we'd probably need to loosen off the bat, and\n>> they're all pretty harmless. But it would be a potential irritating\n>> regression for somebody if they have a history with other minor\n>> flaws, and Git suddenly starts refusing to clone it.\n>\n> The linked issue on bugs.debian.org has seen activity recently, which\n> is the main reason I mentioned it separately as still relevant:\n> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227\n\nI take it back: last activity was in Feb 2016. >_<\n"},{"id":"310941","messageId":"20170206203214.5y6ynn5co7davtrj@sigill.intra.peff.net","threadId":"45062","inReplyTo":"CAJZjrdWq+xSEoTypA_hWdQJgioGOHJd3V7djeQ0YxpzvhuoM=g@mail.gmail.com","subject":"Re: warning in tree xxx: contains zero-padded file modes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-06T20:32:15Z","receivedAt":"2017-02-06T20:32:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote:\n\n> >> There are some discussions in the past [1] [2] about this.\n> \n> I think you forgot to link to [2] :p\n\nI think the [1] [2] there were recursive quotes from Duy's email. Those\nfootnotes were:\n\n[1] http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com%3E/\n[2] http://public-inbox.org/git/%3C20100326215600.GA10910@spearce.org%3E/\n\n> The linked issue on bugs.debian.org has seen activity recently, which\n> is the main reason I mentioned it separately as still relevant:\n> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227\n\nYeah. I think that's not quite solvable with Git as we have it now. We\nhave fsck.* and receive.fsck.* to tweak severity levels, but no matching\nfetch.fsck.* for handling a push (and presumably a transfer.fsck.* to\ncover both fetching and pushing). So there's a potential patch series\nfor anybody interested.\n\n-Peff\n"}]}