On Thu, Aug 20, 2020 at 02:37:55PM +0200, Lukas Straub wrote: > > Right now git-fsck complains about ".git" appearing in a tree, and that > > check blocks people from pushing such trees to any hosting sites that > > enable transfer.fsckObjects (which includes hosters like GitHub). So > > you'd not only need to allow the behavior to be loosened for all of the > > people using the feature, but you'd need to convince server-side hosters > > to loosen their config. And because part of the purpose is to protect > > downstream clients from attacks, I doubt that public hosters like GitHub > > would do so. > > I guess they can add a checkbox to their (secured) web-ui to configure > this. No, that would defeat the purpose. Hosting sites aren't protecting users from themselves. They're concerned about malicious actors pushing up objects that violate expectations and make the hosting site a vector for attacks. Either against other parts of the site, or against downstream users who aren't running fully-patched versions of Git (or perhaps are running a misconfigured one, if there's a known-unsafe configuration). I don't know of a version of Git that's vulnerable to ".git" (it should be blocked from entering the index by verify_path()), but the fsck checks are one layer of a multiple-layer defense against such problems (which have helped us contain other path-related vulnerabilities). Letting the potential attacker turn off that layer makes it pointless. > In the worst-case where the hosting sites don't adopt this config, the user > enables and uses this feature despite the warnings and then wants to use a > hosting site, he can still rewrite the history. Not nice, but no disaster > either. In general, I do like to err on the side of providing users tools to shoot themselves in the foot. But this feels like it crosses even my bar for a foot-gun, especially when there are other solutions available. -Peff
