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

From: Taylor Blau <me@ttaylorr.com>
Date: Oct 8, 2025, 21:49 UTC
Message-ID: <aObceC/Ec/TGTEnv@nand.local>
In-Reply-To: <aObX4C7lMHRnjbYq@nand.local>

On Wed, Oct 08, 2025 at 05:30:08PM -0400, Taylor Blau wrote:

Show 11 quoted lines

> On Wed, Oct 08, 2025 at 11:02:03PM +0200, Michael Lohmann wrote:
> > * Proposed solution (keeping all existing features):
> > - On first use, git generates a secret "token" (e.g. a random string in
> >   ~/.gitsecret)
> > - On calling `git init` or `git clone`, the secret is copied into the
> >   new .git directory and serves as proof that this clone was created by
> >   this user
>
> Sure, but the problem is not with direct clones (at least, not using the
> --local optimization), but with clones that recursively clone other
> submodules.

This is a think-o. I meant to ask whether or not we would respect the token from the top-most $GIT_DIR in nested bare repositories. I imagine we would not (otherwise this proposal would not provide any additional security guarantees), and so...

Show 8 quoted lines

> > - Editors would no longer need to prompt the user for "Do you trust this
> >   repository?" in most cases, because git could prove the clone is user
> >   generated.
>
> If the above is true (that Git would not copy the token into recursively
> cloned submodules), then I admit to struggling a bit to see how this
> proposal would remove the need to consult the user in this case. Instead
> of the editor doing it, the user would need to do it themselves?

The rest is the same as before (swapping submodules for nested bare repositories).

Thanks, Taylor