Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: >> Nice - a more strict spin on proposal 3 from above, if I understand it >> right. Rather than allowing any and all bare repos, avoid someone >> sneaking in a malicious one next to legitimate ones by using an >> allowlist. Seems reasonable to me. > > Ah, another thing I forgot to mention. There has been a little > discussion in the past about isolating "safe" parts of config (and > gitdir) from "unsafe" parts, e.g. "which configs and embedded scripts > are executables", to help better protect from zipfile-type attacks, > which are very similar to this kind of attack. I wonder if it makes > sense to consider that sort of thing as a needswork for this bugfix? > e.g. "/* NEEDSWORK: Only ignore unsafe configs and hooks instead of > ignoring the entire embedded config and hooks in the future */"? There have been such discussions in the past and they all went nowhere because such safe-listing fundamentally does not work. What you consider "safe" today may turn out to be "unsafe" and in a later version of Git will stop honoring it, and for those who depended on it being listed as "safe", such a security fix will be a regression. Disabling the whole thing if the file can be tainted is the only sensible way forward without promising users that they will be hurt by such changes/regressions in the future, I would think. So, no, I do not think such a NEEDSWORK comment is welcome. Thanks.
