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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html