Re: [PATCH] receive-pack: fix crash on out-of-namespace symref

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 30, 2025, 00:37 UTC
Message-ID: <xmqqbjjgiz3a.fsf@gitster.g>
In-Reply-To: <a16bf8a6-2f57-4794-91b5-92615f184c4b@app.fastmail.com>

"Troels Thomsen" <troels@thomsen.io> writes:

Show 18 quoted lines

> On Sun, Dec 28, 2025, at 15:57, Junio C Hamano wrote:
>
>> Fixing crash is certainly a good thing, but when the namespace is
>> segregated and receive-pack wants to get updates only within the
>> given namespace, would presence of such a cross namespace symref
>> cause updates outside the namespace through the symref, defeating
>> the point of setting up a namespace in the first place?
>>
>> I am not objecting to the new behaviour, but am not sure if it is a
>> sensible one.  You _might_ be able to argue that an attempt to update
>> underlying refs outside the namespace through such a symbolic ref
>> should result in an error (i.e., a fix to the current crashing
>> behaviour is to die in a controlled way).
>>
>> Thoughts?
>
> I think it's important that the symbolic ref needs to be explicitly
> created on the receiving side.

Yes, and that can cut both ways. In an ideal world without any end-users who make any mistakes, deliberate cross namespace symref may be a handy feature to break out of the namespace jail on purpose in a controlled way.

But if the symref was made to point across the namespace boundary by mistake, catching it as a misconfiguration may be a crucial chance the user has to prevent it from turning into a security incident. And that is why I asked.