Re: [RCF] Secure git against involuntary arb. code execution without feature loss

TL;DR: Thanks to all peoples input I just mentally untangeled/refactored
a few things about the discusion for myself:

* Current situation:
    git assumes an unsafe repo, if neither
        a) the user owns it, nor
        b) it is included in "safe.directory" config
    and then refuses any operation.

* Suggestions from the discussion:
1) The suggested "token" approach is just an additional way to set the
   current state of allow "safe.directory" for repos _created_ by this
   user
2) The suggested --assume-(un)safe / GIT_ASSUME_(UN)SAFE are additional
   ways of setting the same state temporarily
3) There are suggested improvements on not blankly refusing operation at
   all if assumed to be unsafe
4) The _enforcement_ part of the RFC is about dropping the check for the
   owner of the repo to assume if safe or not

I think 1)-3) are relatively independent of one another to discuss,
whereas 4) probably requires all others to be viable.



And now for the long answer:

We've discussed this a few times over the years. The most recent one I
can remember is:

  https://lore.kernel.org/git/ZZr-JLxubCvWe0EU@tapette.crustytoothpaste.net/ (local)

  1. How does Git behave differently in an "unsafe" context?
     In the thread above, I propose that it should skip loading config
     from the repo-level $GIT_DIR/config file, and turn off hooks
     inside the repo.

Indeed it would be a lot nicer, if git still worked and only showed a
(maybe hideable) warning. As mentioned in the above conversation, the
config parser could only extract the minimum required fields in the
assumed unsafe state and the hooks would be disabled, too.

  2. How does the user tell Git which repos are safe or unsafe? You've
     got a scheme here for marking user-created repositories with a
     secret token. I think that could work, but there are other simpler
     methods. E.g., we could pass down information through the
     environment

I am not sure I can follow you. Just as an overwrite like you mentioned
below / as in suggestion 2)?

     or mark a list of safe directories in user- or system-level
     config (like we have already with safe.directories).
     It's perhaps even reasonable to have multiple such mechanisms, as
     they have different tradeoffs in convenience and security.

Indeed! E.g. for "automated trusting" on init/clone the path based
approach is probably not the best, since
a) if the user runs `git init /trusted && mv /trusted /elsewhere`, all
   of the sudden git would no longer work in that repo and
b) now the path "/trusted" is vulnerable, unknown to the user.

So in some sense I think talking about this token scheme and Git 3.0
compatibility is putting the cart before the horse. We need (1) first.

IMHO, an option on how to _detect_ if this repo is a "safe.directory"
would not depend on improvements on how to _act_ upon it (or the other
way around). Yes - to _enforce_ not whitelisting all user owned repos by
default any more, both are probably needed. So indeed this part is more
speculative.

-Michael