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

[Michael Lohmann <git@lohmann.sh>]

(Sorry @Brian, the first time I forgot to add the mailing list in cc,
and the second time I didn't have my mail client under control adding
HTML... Now trying with send-mail again in order to try and reduce the
possible errors. I am sorry, I am still quite inexperienced with the
mailing list and you need to suffer from my stupid mistakes!)

On Wed, 8 Oct 2025 21:35:56, brian m. carlson wrote:
> This has all of the downsides of our existing per-Unix user approach and
> is also more complicated.  You'll notice that when we changed to the
> per-Unix user approach, that broke containers, shared repositories, and
> even the detection of whether a directory _is_ a repository, and this
> would do the same thing.  It would be even worse for containers because
> if you copied a token into the container from the container user, you'd
> end up polluting that directory with lots of useless tokens that never
> get cleaned up.

Since I never worked in such a scenario, I think I am missing the full
implications. Instead of always requiring that, you could simply set
something like GIT_ALLOW=true or pass `--allow` (or maybe even a _global
only_ config `safe.allow = *` and then you explicitly opt out of this
protection for cases like this.

> It is also easy to bypass, since if we share multiple repositories as
> collaborators, as soon as I can read the secret from one of them, I can
> then write it into any other location.

Then instead of having a single file with all the tokens of users,
create different files with the respective user as the only one allowed
to read.

> It would even be sufficient if we were users on the same system (such
> as is common in universities or some businesses) and I could read the
> repository.  Many websites even accidentally expose their `.git`
> directories, which would not only expose their repository but also
> allow attacks against all of the administrator's repositories.

What is different to the current situation then, apart from that you
specifically have to leak that secret and you now have to be targeted
individually and if you notice it being compromised you can rotate it?

Maybe instead of a shared global secret, create individuals you can
revoke independently?

> What would be better to see instead is a config option that restricts
> which external commands (via config options or hooks) can be executed
> from local config.  Then it would be possible to say, "Never honour
> local config to execute code."  With `includeIf`, this can allowlist
> certain repositories to do that and leave the rest disabled.
> 
> Maybe something like this:
> 
> [safe]
>  config = core.editor
>  config = core.fsmonitor
>  hook = pre-receive

Interesting idea!