Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > It is definitely good to keep in mind that other repositories have > included bare repositories for convenience. I'm not sure that the behavior > of some good actors should outweigh the benefits of protecting against > this attack vector. Good line of thinking. > 2. Suppress warnings on trusted repos, scoped to a specific set of known > trees _or_ based on some set of known commits (in case the known trees > are too large). Is "It is OK to check out an embedded repository from this commit or any of its ancestors" the kind of suppression you meant by "known commits"? > 3. Prevent writing a bare repo to the worktree, unless the user provided > an opt-in to that behavior. > > Since your patch is moving in the right direction here, I don't think > steps (2) and (3) are required to move forward with your patch. However, > it is a good opportunity to discuss the full repercussions of this issue. We can definitely start without (3). Unleashing (1) before (2) is ready would mean folks cannot clone projects like libgit2 until later, which takes us back to the first point you made above. Those who use embedded bare repositories as test vector can easily switch to storing an equivalent of "a tarball that is expanded while building and/or testing", and as long as the user trusts the project enough to run its build procedure or tests, we are not adding much to the attack surface, I would guess.
