git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>,  Jeff King <peff@peff.net>
Subject: Re: [PATCH 0/1] Restore the ability to clone repositories owned by another user
Date: Fri, 15 Nov 2024 10:14:48 +0900	[thread overview]
Message-ID: <xmqqr07d47sn.fsf@gitster.g> (raw)
In-Reply-To: <20241115005404.3747302-1-sandals@crustytoothpaste.net> (brian m. carlson's message of "Fri, 15 Nov 2024 00:54:03 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> For a long time, we've told users that the only safe way to operate on
> an untrusted repository is to clone or fetch from it.  We've even
> mentioned this policy in a variety of places in our documentation.
>
> However, f4aa8c8bb1 ("fetch/clone: detect dubious ownership of local
> repositories", 2024-04-10), this changed in an attempt to make things
> more secure.  That broke a lot of user use cases, which have been
> reported to the list.
>
> Because our security model hasn't changed and it's still safe to clone
> or fetch from an untrusted repository, let's revert a portion of that
> change to allow us to clone and fetch from repositories owned by a
> different user.  If a malicious repository were a problem for
> upload-pack, that would probably also be exploitable on major forges,
> and if it were a problem on the client side, then we'd also have a
> problem with untrusted HTTPS remotes, so we're not really adding any
> security risk here.

Nice.  Better late than never.

> This matter was discussed extensively in the thread starting at
> https://lore.kernel.org/git/ZqUc8DJ1uKcHYlcy@imp.flyn.org/.

> Note that I haven't signed off on this patch because it's based on one
> from Junio and I haven't gotten his sign-off yet.  It's fine to add mine
> once he's added his.

You can forge my sign-off on the old patch ;-)

The proposed commit log of the patch makes me wonder what should
happen when neither of the two bits is set.  Not strict, but we do
not allow ourselves to enter a random repo owned by a stranger.  It
turns out that "strict" has nothing to do with this lifting of
excess ownership check, but the dwimming done by suffixing .git,
etc. to the given pathnames, so there is nothing strange going on.

Thanks.

  parent reply	other threads:[~2024-11-15  1:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15  0:54 [PATCH 0/1] Restore the ability to clone repositories owned by another user brian m. carlson
2024-11-15  0:54 ` [PATCH 1/1] Allow cloning from " brian m. carlson
2025-03-31 13:14   ` SZEDER Gábor
2025-03-31 21:53     ` brian m. carlson
2024-11-15  1:14 ` Junio C Hamano [this message]
2024-11-15  2:02   ` [PATCH 0/1] Restore the ability to clone " brian m. carlson
2024-11-26  7:28 ` Junio C Hamano
2024-11-28 17:27   ` brian m. carlson

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=xmqqr07d47sn.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /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).