Junio C Hamano <gitster@xxxxxxxxx> writes: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >> Is there anything we can or should do to prevent people checking in >> new examples of paths with backslash in them (on all platforms)? > > I obviously won't dictate what should happen on Windows, but I think > the overall principle for paths recorded in a tree object that can > be problematic on some of the platforms ought to be: > > * fsck and transfer.fsckobjects should be taught to notice > offending characteristics (e.g. has a backslash in it, is one of > the "reserved names" on some platform like LPT1). > > * if paths with the offending characteristics are *so* obviously > useless in real life and are possible only in a crafted path that > is only useful to attack users, the check in fsck should default > to "reject" to help the disease spread via hosting sites. > > * otherwise, the check should be to "warn" but not "reject", so > that projects can keep using paths that may problematic on > platforms that do not matter to them. > > I think LPT1 and friends fall into the "warning is fine" category, > and a path component that contains a backslash would fall into the > "this is an attack, just reject" category. I guess I should have stepped back a bit. In the message I am responding to, I focused solely on how tree objects that originate elsewhere should be treated, but there are two more data paths we need to worry about: * A new path gets introduced to the system, via "update-index", "add", etc., to the index and then "write-tree" to form tree objects in the local repository. * A path in the index, either created locally via "update-index", "add", etc., or read from a tree object, gets written to the local filesystem, resulting in an attempt to create a path that the local filesystem cannot represent (or worse---behaves badly, like "sending random garbage to the printer"). I think we should apply the same principle as the one I outlined for the tree objects. The fsckobjects mechanism may not be reusable to catch violations in add_index_entry_with_check() as-is, but we need to aim for as much reuse of logic and code as possible so that our checks at various layers all behave consistently. Thanks.
