5 ms·

The exploit being referenced allows malicious code to be injected into a file that handles git, which is (.git). Now, normally Git does not allow you to overwri

The exploit being referenced allows malicious code to be injected into a file that handles git, which is (.git). Now, normally Git does not allow you to overwrite (.git). Since HFS+ is case-insensitive, writing the file as (.Git) will overwrite the (.git) file and break security. Linus is saying that an uppercase and lowercase character are two different things, and not recognizing that can (and did) cause problems with security.

Arnavion 12y ago
His argument is wrong. The issue is not with the filesystem being case-insensitive; the issue is that some strings which are not identical map to the same filename. Two strings differing in case is only one such example. Another example is the presence of codepoints which are ignored by the filesystem. The fix for git and Mercurial included the fix for this as well. Does Linus think all filesystems should allow all 256 byte sequences in every permutation as well? (He might, since that is the behavior of common Linux filesystems.) The proper mindset is to realize the actual issue (multiple strings map to the same filename) and use a "filename_according_to_program -> filename_according_to_filesystem" function everywhere when dealing with filenames, not to blame the filesystem.
- dennisnedry 12y ago
  You hit the nail on the head, he does expect things to work almost exactly as they do on Linux. The thing about Linus if you've ever spent any time on reading the Linux Kernel mailing list is that he is extremely explosive and at times has really harsh analogies. But...he is usually right.
- daxelrod 12y ago
  The question you need the filesystem to answer in this case is, "If I save a file with name A, will it be accessible via name B?" You can't assume that the filesystem has one canonical name from which the file will be accessed. EDIT: That actually isn't even enough, because the answer may vary by locale. Even worse, to solve this for Git's case, you need to know the answer 1) For every locale 2) For every supported filesystem

Arnavion 12y ago

His argument is wrong. The issue is not with the filesystem being case-insensitive; the issue is that some strings which are not identical map to the same filename. Two strings differing in case is only one such example. Another example is the presence of codepoints which are ignored by the filesystem. The fix for git and Mercurial included the fix for this as well. Does Linus think all filesystems should allow all 256 byte sequences in every permutation as well? (He might, since that is the behavior of common Linux filesystems.) The proper mindset is to realize the actual issue (multiple strings map to the same filename) and use a "filename_according_to_program -> filename_according_to_filesystem" function everywhere when dealing with filenames, not to blame the filesystem.

dennisnedry 12y ago
You hit the nail on the head, he does expect things to work almost exactly as they do on Linux. The thing about Linus if you've ever spent any time on reading the Linux Kernel mailing list is that he is extremely explosive and at times has really harsh analogies. But...he is usually right.
daxelrod 12y ago
The question you need the filesystem to answer in this case is, "If I save a file with name A, will it be accessible via name B?" You can't assume that the filesystem has one canonical name from which the file will be accessed. EDIT: That actually isn't even enough, because the answer may vary by locale. Even worse, to solve this for Git's case, you need to know the answer 1) For every locale 2) For every supported filesystem