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

["Troels Thomsen" <troels@thomsen.io>]

On Sat, Feb 21, 2026, at 18:00, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> "Troels Thomsen" <troels@thomsen.io> writes:
>>
>>> 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.
>
> The review discussion thread ended here.  I am dropping the topic
> out of my tree now, but I do not think it would be a bad idea to
> resurrect the topic that turns the uncontrolled segmentation fault
> into a controlled death that calls die("hey, what is that cross
> namespace link doing there?").
>
> Thanks.

Do you think your original concern could be addressed by adding a note
to the security section of gitnamespaces?

It seems somewhat relevant that you're unlikely to create a symbolic ref
within a namespace without first consulting the documentation to
understand the ref format. Combined with the lack of interest in this
thread, and the fact that no bug report was filed for years, I suspect
this feature combination is rare. That's not a good reason for a bad
default, but a symbolic ref can already point outside a namespace; you
only can't update it.

If I fix it by rejecting updates as suggested, I still wouldn't be able
to do what I wanted in the first place. Is there a better way to propose
such a change?

In any case, thank you for your time.

-- 
Troels Thomsen