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

[Junio C Hamano <gitster@pobox.com>]

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.