git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Michael Lohmann <git@lohmann.sh>
Cc: git@vger.kernel.org
Subject: Re: [RCF] Secure git against involuntary arb. code execution without feature loss
Date: Wed, 8 Oct 2025 17:49:44 -0400	[thread overview]
Message-ID: <aObceC/Ec/TGTEnv@nand.local> (raw)
In-Reply-To: <aObX4C7lMHRnjbYq@nand.local>

On Wed, Oct 08, 2025 at 05:30:08PM -0400, 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.

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...

> > - 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

  parent reply	other threads:[~2025-10-08 21:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-08 21:02 [RCF] Secure git against involuntary arb. code execution without feature loss Michael Lohmann
2025-10-08 21:30 ` Taylor Blau
2025-10-08 21:34   ` rsbecker
2025-10-08 21:49   ` Taylor Blau [this message]
2025-10-08 22:09     ` Michael Lohmann
2025-10-08 21:35 ` brian m. carlson
2025-10-08 22:25   ` Michael Lohmann
2025-10-09  5:24 ` Jeff King
2025-10-09 22:43   ` Michael Lohmann
2025-10-13  9:57   ` Submitted patches for "assume unsafe" Michael Lohmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aObceC/Ec/TGTEnv@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@lohmann.sh \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).