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

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

quoted

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