Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

From: Jeff King <peff@peff.net>
Date: Aug 16, 2016, 14:55 UTC
Message-ID: <20160816145532.nfooqmkaostc2e7t@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1608161502240.4924@virtualbox>

On Tue, Aug 16, 2016 at 03:10:46PM +0200, Johannes Schindelin wrote:

Show 16 quoted lines

> > I am not convinced this mechanism needs to be built into git. Because it
> > happens to be about filenames, git at least has a hope of making sense
> > of the various project rules.
> 
> Both of you gentle people may recall a conversation in December 2014 when
> we scrambled to plug a hole where maliciously-chosen file names would have
> allowed to wreak havoc with a local Git repository's config (among other
> things).
> 
> We did plug it, but not before I proposed to exclude many more file names
> than just maliciously-chosen ones. For example, I wanted to exclude all
> file names that are illegal on Windows when core.protectNTFS was set to
> true.
> 
> If we were to implement this "let's help cross-platform projects"
> functionality, it would be at that same level.

Hrm. I am not sure I agree. At GitHub, for instance, we turn on core.protectNTFS for all repositories because we do want to be a vector for attacks. So the tradeoff is a good one: the restrictions on filenames are not that big, and we gain a lot of safety (i.e., a known remote code execution bug).

Whereas if core.protectNTFS started disallowing trees with both "foo" and "FOO", that is a much different tradeoff. It is much more likely to come up, and it is protecting a much less valuable thing (it's an annoyance, not a security hole). Projects which do not care about people on case-insensitive filesystems will be annoyed to have their commits rejected (whether they are right to be so uncaring or not can be debated, but I am not sure that GitHub wants to enforce a hard policy at the fsck layer).

So even if we wanted a similar mechanism, I think it has to be triggered by a separate config option. And I do not think general hosting sites would turn it on. It's really a project decision, not a hosting-site one.

There may be some rules that are in between. I.e., names that are illegal on some common platform but are extremely unlikely to be chosen in general. I'd have to see the rules to give an opinion.

-Peff