From: rsbecker@nexbridge.com
Date: Wed, 08 Oct 2025 21:34:56 GMT
Subject: RE: [RCF] Secure git against involuntary arb. code execution without feature loss
Message-ID: <020201dc389b$677305f0$365911d0$@nexbridge.com>
In-Reply-To: <aObX4C7lMHRnjbYq@nand.local>

On October 8, 2025 5:30 PM, Taylor Blau wrote:
>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.
>
>If I clone a repository with --recurse-submodules, I imagine that this proposal
>would *not* suggest copying this token into the recursively cloned submodules,
>right?
>proposal improves the experience
>
>> - 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?

I am wondering why this approach cannot be made more general. If there is
a tokenization framework built into git that organizations can use for integration,
they should be able to plug-in their own approved tokenization solutions, which
have already been vetted by the security groups. I am concerned that we are
potentially opening up git to CVEs due to insufficiently secure tokens that are
outside our specific domain.

--Randall