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. 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

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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to