Re: [PATCH] is_hfs_dotgit: loosen over-eager match of \u{..47}

[Jeff King <peff@peff.net>]

On Tue, Dec 23, 2014 at 04:24:57PM +0100, Torsten Bögershausen wrote:

> Don't we have the same possible problem under NTFS?
> Under Linux + VFAT ?
> Under all OS + VFAT ?

I'm not sure what you mean.

This code path is _only_ about checking for HFS+-specific problems. We
check general case-insensitivity in another code path. And we check
NTFS-specific problems in another code path.

(Technically we could make a "check all" function that runs over the
data only once, which would be more efficient. But doing it this way
makes the code much easier to follow).

> And would it make sense to turn this
> >   return (out & 0xffffff00) ? out : tolower(out);
> into this:
> static ucs_char_t unicode_tolower(ucs_char_t ch) {
>    return (ch & 0xffffff00) ? ch : tolower(ch);
> }

Perhaps, but you would need a big warning at the top of that function
that is _only_ downcasing ASCII characters. I.e., it is fine for our use
here, but you would not want other unicode-aware code to call it. The
next_hfs_char already has such a warning at the top.

> And what happens if I export NTFS to Mac OS X?
> (Other combinations possible)
> Shouldn't fsck under all OS warn for NTFS and hfs possible attacks ?

Fsck already warns for all system types, no matter what platform you're
on. And we do case-insensitive blocking of ".git" entering the index for
all platforms.

We don't turn on filesystem-specific blocking of paths entering the
index on all platforms. You get HFS+ blocking by default on OS X, and
NTFS on Windows. If you are using HFS+ on Linux, you should set
core.protectHFS.

Possibly we should just turn on all checks everywhere. That would be a
safer default, at the cost to Linux folks of:

  1. Some slight inefficiency in each read-tree, as we have to do extra
     processing on each name.

  2. Some names would be disallowed that are otherwise OK. For the most
     part these are not names that would be used in practice, though
     (e.g., losing the ability to create ".git\u200c" is not a big loss
     to anyone). I think Git for Windows has started blocking other
     stuff like "CON" that is not specifically related to .git, though,
     and that is more plausible for somebody to use in real life.

-Peff