On Fri, Mar 14, 2025 at 6:28 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > Because the "[remote "nick"] fetch = ..." configuration variables > > have the nickname in the second part, the nicknames are case > > sensitive, unlike the first and the third component (i.e. > > "remote.origin.fetch" and "Remote.origin.FETCH" are the same thing, > > but "remote.Origin.fetch" and "remote.origin.fetch" are different). > > I double-checked what the control flow that passes through > remote.c:handle_config() does, and the above is in line with what > remote_get() does. > > remote.c:read_config() populates the nickname-to-remote hashmap by > using handle_config() callback, which calls make_remote() with the > second level name (e.g. "Origin" and "origin" in the last example of > the above), which is passed to memhash() not memihash() when looking > up or registering the remote. > > If we used case insensitive comparison in the new code, a malicious > large-object promisor remote could have told us to use "Origin" as > an extra promisor and in response the new code may noticed that we > have "origin" and tried to equate it with what the other side told > us. But when the existing code actually interacts with the promisor > remote, it wouldn't have found any configured remote under the name > "Origin", and something funny would start from there. By using the > right remote consistently throughout the system, we would not get > confused that way, which is good. Yeah, right. Thanks for looking into it. I don't think this needs to be in the commit message, so I haven't changed this patch in the next version. But I would be fine with adding your explanations or something similar if someone thinks it's worth it.
