[PATCH 0/1] Restore the ability to clone repositories owned by another user

[PATCH 0/1] Restore the ability to clone repositories owned by another user

[brian m. carlson]

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.

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.

brian m. carlson (1):
  Allow cloning from repositories owned by another user

 Documentation/git-clone.txt   |  9 +++++++++
 builtin/upload-pack.c         |  5 ++++-
 daemon.c                      |  6 ++++--
 path.c                        | 10 ++++++----
 path.h                        | 17 ++++++++++++++++-
 t/t0411-clone-from-partial.sh |  3 ---
 t/t5605-clone-local.sh        | 10 ++++++++++
 7 files changed, 49 insertions(+), 11 deletions(-)

[PATCH 1/1] Allow cloning from repositories owned by another user

[brian m. carlson]

Historically, Git has allowed users to clone from an untrusted
repository, and we have documented that this is safe to do so:

    `upload-pack` tries to avoid any dangerous configuration options or
    hooks from the repository it's serving, making it safe to clone an
    untrusted directory and run commands on the resulting clone.

However, this was broken by f4aa8c8bb1 ("fetch/clone: detect dubious
ownership of local repositories", 2024-04-10) in an attempt to make
things more secure.  That change resulted in a variety of problems when
cloning locally and over SSH, but it did not change the stated security
boundary.  Because the security boundary has not changed, it is safe to
adjust part of the code that patch introduced.

To do that and restore the previous functionality, adjust enter_repo to
take two flags instead of one.

The two bits are

 - ENTER_REPO_STRICT: callers that require exact paths (as opposed
   to allowing known suffixes like ".git", ".git/.git" to be
   omitted) can set this bit.  Corresponds to the "strict" parameter
   that the flags word replaces.

 - ENTER_REPO_ANY_OWNER_OK: callers that are willing to run without
   ownership check can set this bit.

The former is --strict-paths option of "git daemon".  The latter is
set only by upload-pack, which honors the claimed security boundary.

Note that local clones across ownership boundaries require --no-local so
that upload-pack is used.  Document this fact in the manual page and
provide an example.

This patch was based on one written by Junio C Hamano.
---
 Documentation/git-clone.txt   |  9 +++++++++
 builtin/upload-pack.c         |  5 ++++-
 daemon.c                      |  6 ++++--
 path.c                        | 10 ++++++----
 path.h                        | 17 ++++++++++++++++-
 t/t0411-clone-from-partial.sh |  3 ---
 t/t5605-clone-local.sh        | 10 ++++++++++
 7 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7acb4cb176..de8d8f5893 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -63,6 +63,9 @@ symbolic link, the clone will fail. This is a security measure to
 prevent the unintentional copying of files by dereferencing the symbolic
 links.
 +
+This option does not work with repositories owned by other users for security
+reasons, and `--no-local` must be specified for the clone to succeed.
++
 *NOTE*: this operation can race with concurrent modification to the
 source repository, similar to running `cp -r <src> <dst>` while modifying
 _<src>_.
@@ -384,6 +387,12 @@ $ cd my-linux
 $ git clone --bare -l /home/proj/.git /pub/scm/proj.git
 ------------
 
+* Clone a local repository from a different user:
++
+------------
+$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
+------------
+
 CONFIGURATION
 -------------
 
diff --git a/builtin/upload-pack.c b/builtin/upload-pack.c
index 3b6c83fbce..dd63d6eadf 100644
--- a/builtin/upload-pack.c
+++ b/builtin/upload-pack.c
@@ -39,6 +39,7 @@ int cmd_upload_pack(int argc,
 			    N_("interrupt transfer after <n> seconds of inactivity")),
 		OPT_END()
 	};
+	unsigned enter_repo_flags = ENTER_REPO_ANY_OWNER_OK;
 
 	packet_trace_identity("upload-pack");
 	disable_replace_refs();
@@ -54,7 +55,9 @@ int cmd_upload_pack(int argc,
 
 	dir = argv[0];
 
-	if (!enter_repo(dir, strict))
+	if (strict)
+		enter_repo_flags |= ENTER_REPO_STRICT;
+	if (!enter_repo(dir, enter_repo_flags))
 		die("'%s' does not appear to be a git repository", dir);
 
 	switch (determine_protocol_version_server()) {
diff --git a/daemon.c b/daemon.c
index a40e435c63..756c3f0b02 100644
--- a/daemon.c
+++ b/daemon.c
@@ -152,6 +152,7 @@ static const char *path_ok(const char *directory, struct hostinfo *hi)
 	size_t rlen;
 	const char *path;
 	const char *dir;
+	unsigned enter_repo_flags;
 
 	dir = directory;
 
@@ -242,14 +243,15 @@ static const char *path_ok(const char *directory, struct hostinfo *hi)
 		dir = rpath;
 	}
 
-	path = enter_repo(dir, strict_paths);
+	enter_repo_flags = strict_paths ? ENTER_REPO_STRICT : 0;
+	path = enter_repo(dir, enter_repo_flags);
 	if (!path && base_path && base_path_relaxed) {
 		/*
 		 * if we fail and base_path_relaxed is enabled, try without
 		 * prefixing the base path
 		 */
 		dir = directory;
-		path = enter_repo(dir, strict_paths);
+		path = enter_repo(dir, enter_repo_flags);
 	}
 
 	if (!path) {
diff --git a/path.c b/path.c
index 93491bab14..4dcf3c8d40 100644
--- a/path.c
+++ b/path.c
@@ -684,7 +684,7 @@ char *interpolate_path(const char *path, int real_home)
  * links.  User relative paths are also returned as they are given,
  * except DWIM suffixing.
  */
-const char *enter_repo(const char *path, int strict)
+const char *enter_repo(const char *path, unsigned flags)
 {
 	static struct strbuf validated_path = STRBUF_INIT;
 	static struct strbuf used_path = STRBUF_INIT;
@@ -692,7 +692,7 @@ const char *enter_repo(const char *path, int strict)
 	if (!path)
 		return NULL;
 
-	if (!strict) {
+	if (!(flags & ENTER_REPO_STRICT)) {
 		static const char *suffix[] = {
 			"/.git", "", ".git/.git", ".git", NULL,
 		};
@@ -736,7 +736,8 @@ const char *enter_repo(const char *path, int strict)
 		if (!suffix[i])
 			return NULL;
 		gitfile = read_gitfile(used_path.buf);
-		die_upon_dubious_ownership(gitfile, NULL, used_path.buf);
+		if (!(flags & ENTER_REPO_ANY_OWNER_OK))
+			die_upon_dubious_ownership(gitfile, NULL, used_path.buf);
 		if (gitfile) {
 			strbuf_reset(&used_path);
 			strbuf_addstr(&used_path, gitfile);
@@ -747,7 +748,8 @@ const char *enter_repo(const char *path, int strict)
 	}
 	else {
 		const char *gitfile = read_gitfile(path);
-		die_upon_dubious_ownership(gitfile, NULL, path);
+		if (!(flags & ENTER_REPO_ANY_OWNER_OK))
+			die_upon_dubious_ownership(gitfile, NULL, path);
 		if (gitfile)
 			path = gitfile;
 		if (chdir(path))
diff --git a/path.h b/path.h
index e91d19fff6..5f6c85e5f8 100644
--- a/path.h
+++ b/path.h
@@ -156,7 +156,22 @@ int calc_shared_perm(int mode);
 int adjust_shared_perm(const char *path);
 
 char *interpolate_path(const char *path, int real_home);
-const char *enter_repo(const char *path, int strict);
+
+/* The bits are as follows:
+ *
+ * - ENTER_REPO_STRICT: callers that require exact paths (as opposed
+ *   to allowing known suffixes like ".git", ".git/.git" to be
+ *   omitted) can set this bit.
+ *
+ * - ENTER_REPO_ANY_OWNER_OK: callers that are willing to run without
+ *   ownership check can set this bit.
+ */
+enum {
+	ENTER_REPO_STRICT = (1<<0),
+	ENTER_REPO_ANY_OWNER_OK = (1<<1),
+};
+
+const char *enter_repo(const char *path, unsigned flags);
 const char *remove_leading_path(const char *in, const char *prefix);
 const char *relative_path(const char *in, const char *prefix, struct strbuf *sb);
 int normalize_path_copy_len(char *dst, const char *src, int *prefix_len);
diff --git a/t/t0411-clone-from-partial.sh b/t/t0411-clone-from-partial.sh
index 932bf2067d..2aff6261e4 100755
--- a/t/t0411-clone-from-partial.sh
+++ b/t/t0411-clone-from-partial.sh
@@ -29,7 +29,6 @@ test_expect_success 'local clone must not fetch from promisor remote and execute
 	test_must_fail git clone \
 		--upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
 		evil clone1 2>err &&
-	test_grep "detected dubious ownership" err &&
 	test_grep ! "fake-upload-pack running" err &&
 	test_path_is_missing script-executed
 '
@@ -39,7 +38,6 @@ test_expect_success 'clone from file://... must not fetch from promisor remote a
 	test_must_fail git clone \
 		--upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
 		"file://$(pwd)/evil" clone2 2>err &&
-	test_grep "detected dubious ownership" err &&
 	test_grep ! "fake-upload-pack running" err &&
 	test_path_is_missing script-executed
 '
@@ -49,7 +47,6 @@ test_expect_success 'fetch from file://... must not fetch from promisor remote a
 	test_must_fail git fetch \
 		--upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
 		"file://$(pwd)/evil" 2>err &&
-	test_grep "detected dubious ownership" err &&
 	test_grep ! "fake-upload-pack running" err &&
 	test_path_is_missing script-executed
 '
diff --git a/t/t5605-clone-local.sh b/t/t5605-clone-local.sh
index d9a320abd2..286099390c 100755
--- a/t/t5605-clone-local.sh
+++ b/t/t5605-clone-local.sh
@@ -154,6 +154,16 @@ test_expect_success 'cloning a local path with --no-local does not hardlink' '
 	! repo_is_hardlinked force-nonlocal
 '
 
+test_expect_success 'cloning a local path with --no-local from a different user succeeds' '
+	git clone --upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
+		--no-local a nonlocal-otheruser 2>err &&
+	! repo_is_hardlinked nonlocal-otheruser &&
+	# Verify that this is a git repository.
+	git -C nonlocal-otheruser rev-parse --show-toplevel &&
+	! test_grep "detected dubious ownership" err
+
+'
+
 test_expect_success 'cloning locally respects "-u" for fetching refs' '
 	test_must_fail git clone --bare -u false a should_not_work.git
 '

Re: [PATCH 1/1] Allow cloning from repositories owned by another user

[SZEDER Gábor]

On Fri, Nov 15, 2024 at 12:54:04AM +0000, brian m. carlson wrote:
> Historically, Git has allowed users to clone from an untrusted
> repository, and we have documented that this is safe to do so:
> 
>     `upload-pack` tries to avoid any dangerous configuration options or
>     hooks from the repository it's serving, making it safe to clone an
>     untrusted directory and run commands on the resulting clone.
> 
> However, this was broken by f4aa8c8bb1 ("fetch/clone: detect dubious
> ownership of local repositories", 2024-04-10) in an attempt to make
> things more secure.  That change resulted in a variety of problems when
> cloning locally and over SSH, but it did not change the stated security
> boundary.  Because the security boundary has not changed, it is safe to
> adjust part of the code that patch introduced.
> 
> To do that and restore the previous functionality, adjust enter_repo to
> take two flags instead of one.
> 
> The two bits are
> 
>  - ENTER_REPO_STRICT: callers that require exact paths (as opposed
>    to allowing known suffixes like ".git", ".git/.git" to be
>    omitted) can set this bit.  Corresponds to the "strict" parameter
>    that the flags word replaces.
> 
>  - ENTER_REPO_ANY_OWNER_OK: callers that are willing to run without
>    ownership check can set this bit.
> 
> The former is --strict-paths option of "git daemon".  The latter is
> set only by upload-pack, which honors the claimed security boundary.
> 
> Note that local clones across ownership boundaries require --no-local so
> that upload-pack is used.  Document this fact in the manual page and
> provide an example.
> 
> This patch was based on one written by Junio C Hamano.


> diff --git a/t/t5605-clone-local.sh b/t/t5605-clone-local.sh
> index d9a320abd2..286099390c 100755
> --- a/t/t5605-clone-local.sh
> +++ b/t/t5605-clone-local.sh
> @@ -154,6 +154,16 @@ test_expect_success 'cloning a local path with --no-local does not hardlink' '
>  	! repo_is_hardlinked force-nonlocal
>  '
>  
> +test_expect_success 'cloning a local path with --no-local from a different user succeeds' '
> +	git clone --upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
> +		--no-local a nonlocal-otheruser 2>err &&
> +	! repo_is_hardlinked nonlocal-otheruser &&
> +	# Verify that this is a git repository.
> +	git -C nonlocal-otheruser rev-parse --show-toplevel &&
> +	! test_grep "detected dubious ownership" err
> +
> +'

This test succeeds without checking everything it is supposed to:

  + git clone --upload-pack=GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack --no-local a nonlocal-otheruser
  + repo_is_hardlinked nonlocal-otheruser
  + find nonlocal-otheruser/objects -type f -links 1
  find: 'nonlocal-otheruser/objects': No such file or directory
  + git -C nonlocal-otheruser rev-parse --show-toplevel
  /home/szeder/src/git/t/trash directory.t5605-clone-local/nonlocal-otheruser
  + test_grep detected dubious ownership err
  error: 'grep detected dubious ownership err' didn't find a match in:
  Cloning into 'nonlocal-otheruser'...
  warning: remote HEAD refers to nonexistent ref, unable to checkout
  ok 21 - cloning a local path with --no-local from a different user succeeds

The 'repo_is_hardlinked' helper function expects the path to the .git
directory as parameter, but in this case it gets the top-level path of
the repository instead, which results in 'find' rightfully complaining
about the non-existing 'objects' directory.  Thanks to the &&-chain in
'repo_is_hardlinked' this error then causes the helper function to
return with non-zero error code, just what this test case expected.

All other tests using this helper function create bare clones, and
they all pass the right path as parameter.

The trivial fix would be to either use a bare clone in this test as
well, or to pass the right path to 'repo_is_hardlinked', i.e. the path
to the '.git' directory.

The right fix, in my opinion, is to teach 'repo_is_hardlinked' a
negation parameter, so tests expecting the repo to be not hardlinked
could invoke it as 'repo_is_hardlinked ! <path>'.  An error from
'find' within the helper function should then always result in an
error of the helper function, i.e. both with and without that '!'
parameter.

Furthermore, this test should use 'test_grep ! ...' instead of '!
test_grep ...', so we don't get that misleading error message in the
test's output.

And there is a stray empty line at the end of the test as well.

Re: [PATCH 1/1] Allow cloning from repositories owned by another user

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]

On 2025-03-31 at 13:14:12, SZEDER Gábor wrote:
> This test succeeds without checking everything it is supposed to:
> 
>   + git clone --upload-pack=GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack --no-local a nonlocal-otheruser
>   + repo_is_hardlinked nonlocal-otheruser
>   + find nonlocal-otheruser/objects -type f -links 1
>   find: 'nonlocal-otheruser/objects': No such file or directory
>   + git -C nonlocal-otheruser rev-parse --show-toplevel
>   /home/szeder/src/git/t/trash directory.t5605-clone-local/nonlocal-otheruser
>   + test_grep detected dubious ownership err
>   error: 'grep detected dubious ownership err' didn't find a match in:
>   Cloning into 'nonlocal-otheruser'...
>   warning: remote HEAD refers to nonexistent ref, unable to checkout
>   ok 21 - cloning a local path with --no-local from a different user succeeds
> 
> The 'repo_is_hardlinked' helper function expects the path to the .git
> directory as parameter, but in this case it gets the top-level path of
> the repository instead, which results in 'find' rightfully complaining
> about the non-existing 'objects' directory.  Thanks to the &&-chain in
> 'repo_is_hardlinked' this error then causes the helper function to
> return with non-zero error code, just what this test case expected.
> 
> All other tests using this helper function create bare clones, and
> they all pass the right path as parameter.
> 
> The trivial fix would be to either use a bare clone in this test as
> well, or to pass the right path to 'repo_is_hardlinked', i.e. the path
> to the '.git' directory.
> 
> The right fix, in my opinion, is to teach 'repo_is_hardlinked' a
> negation parameter, so tests expecting the repo to be not hardlinked
> could invoke it as 'repo_is_hardlinked ! <path>'.  An error from
> 'find' within the helper function should then always result in an
> error of the helper function, i.e. both with and without that '!'
> parameter.
> 
> Furthermore, this test should use 'test_grep ! ...' instead of '!
> test_grep ...', so we don't get that misleading error message in the
> test's output.
> 
> And there is a stray empty line at the end of the test as well.

Thanks for the report.  I've opted not to teach `repo_is_hardlinked` a
negation parameter, but I have fixed the three items you've mentioned.
Here's a patch.

-- >% --
Subject: [PATCH] t5605: fix test for cloning from a different user

This test currently passes, but for the wrong reason.  The
repo_is_hardlinked function expects a .git directory or a bare
repository and currently fails because it cannot find the objects
directory.

One solution is to use the --bare argument, but then --show-toplevel
won't work.  We could change that, but there's no need to, so just add
the missing .git directory.

In addition, use the built-in negation functionality of test_grep to
avoid mishandling real errors (such as a missing file) and, as a final
fix, remove the extra newline.

Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 t/t5605-clone-local.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/t/t5605-clone-local.sh b/t/t5605-clone-local.sh
index 4605703496..2397f8fa61 100755
--- a/t/t5605-clone-local.sh
+++ b/t/t5605-clone-local.sh
@@ -156,11 +156,10 @@ test_expect_success 'cloning a local path with --no-local does not hardlink' '
 test_expect_success 'cloning a local path with --no-local from a different user succeeds' '
 	git clone --upload-pack="GIT_TEST_ASSUME_DIFFERENT_OWNER=true git-upload-pack" \
 		--no-local a nonlocal-otheruser 2>err &&
-	! repo_is_hardlinked nonlocal-otheruser &&
+	! repo_is_hardlinked nonlocal-otheruser/.git &&
 	# Verify that this is a git repository.
 	git -C nonlocal-otheruser rev-parse --show-toplevel &&
-	! test_grep "detected dubious ownership" err
-
+	test_grep ! "detected dubious ownership" err
 '
 
 test_expect_success 'cloning locally respects "-u" for fetching refs' '
-- 
2.49.0.395.g12beb8f557c
-- >% --

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH 0/1] Restore the ability to clone repositories owned by another user

[Junio C Hamano]

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

Re: [PATCH 0/1] Restore the ability to clone repositories owned by another user

[brian m. carlson]

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

Re: [PATCH 0/1] Restore the ability to clone repositories owned by another user

[Junio C Hamano]

The breakage this fixes was originally meant as an extra "security"
thing that turned out to have a larger blast radius than originally
intended.  I was hoping that many many folks thank us for reversing
the course, but unfortunately we didn't hear much about this topic.

Unless there are strong objections, I'll mark the topic for 'next'
soonish.

Thanks.

Re: [PATCH 0/1] Restore the ability to clone repositories owned by another user

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On 2024-11-26 at 07:28:40, Junio C Hamano wrote:
> The breakage this fixes was originally meant as an extra "security"
> thing that turned out to have a larger blast radius than originally
> intended.  I was hoping that many many folks thank us for reversing
> the course, but unfortunately we didn't hear much about this topic.
> 
> Unless there are strong objections, I'll mark the topic for 'next'
> soonish.

I think that will be fine, thanks.  I expect that a bunch of people who
experienced problems won't notice until this is in a released version,
so we'll probably hear from them after the fact.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]