From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
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 02:02:13 +0000 [thread overview]
Message-ID: <ZzarpTaoooBOBohZ@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqr07d47sn.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]
On 2024-11-15 at 01:14:48, Junio C Hamano wrote:
> "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.
Yeah, I had intended to get to this sooner, but I got busy with other
things, and nobody got to it before me. I had some time so I thought
I'd send this out now so we can minimize the number of affected versions.
I really appreciate you writing up the original patch for this; it was
very helpful and a great start.
> > 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 ;-)
Great. I suspect you'll probably pick this up as-is, but I've added
both our sign-offs in case we need a v2. Let me know if you'd prefer me
to send out the unmodified v2, and I can do that.
> 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.
Exactly.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2024-11-15 2:02 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 ` [PATCH 0/1] Restore the ability to clone " Junio C Hamano
2024-11-15 2:02 ` brian m. carlson [this message]
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=ZzarpTaoooBOBohZ@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.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).