Re: [PATCH v2 4/4] promisor-remote: check advertised name or URL

[Patrick Steinhardt <ps@pks.im>]

Oh, so here you address my previous comments. I'd propose to either
squash those two commits or to not introduce "acceptFromServer" in the
preceding commit in the first place.

On Tue, Sep 10, 2024 at 06:30:00PM +0200, Christian Couder wrote:
> diff --git a/Documentation/config/promisor.txt b/Documentation/config/promisor.txt
> index 9cbfe3e59e..d1364bc018 100644
> --- a/Documentation/config/promisor.txt
> +++ b/Documentation/config/promisor.txt
> @@ -12,9 +12,19 @@ promisor.advertise::
>  promisor.acceptFromServer::
>  	If set to "all", a client will accept all the promisor remotes
>  	a server might advertise using the "promisor-remote"
> -	capability. Default is "none", which means no promisor remote
> -	advertised by a server will be accepted. By accepting a
> -	promisor remote, the client agrees that the server might omit
> -	objects that are lazily fetchable from this promisor remote
> -	from its responses to "fetch" and "clone" requests from the
> -	client. See linkgit:gitprotocol-v2[5].
> +	capability. If set to "knownName" the client will accept
> +	promisor remotes which are already configured on the client
> +	and have the same name as those advertised by the client.

Wait, does this mean that a server can start advertising new promisor
remotes at any point in time and we'd backfill them on the client
whenever we execute git-fetch(1)? That sounds fishy to me -- I wouldn't
want anything to touch my configuration after I have created the repo
unless I explicitly tell it to.

If so, how does this handle the case where I manually added a remote
that by accident (or malicious intent of the server) that matches one of
the newly-advertised promisor remotes? This goes back to one of my
previous comments, where I said that it's likely not a good idea to let
the remote dictate names of our remotes in the first place.

If not, where do the known names come from?

Patrick