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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peff,

On Tue, 16 Aug 2016, Jeff King wrote:

> On Tue, Aug 16, 2016 at 03:10:46PM +0200, Johannes Schindelin wrote:
> 
> > > 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.

I trust you meant "do *not* 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.

Good point.

What I meant in my curt language was actually not to use core.protectNTFS
per se, but the same code path. That is, I would rather have any such
"cross-platform helping" code in verify_path() rather than
write_index_as_tree().

But you are correct, this hypothetical feature (pretty hypothetical,
indeed, at this point) would have to be configured differently than
via core.protectNTFS=true.

Ciao,
Dscho