From: Junio C Hamano Date: Sat, 21 Feb 2026 17:00:05 GMT Subject: Re: [PATCH] receive-pack: fix crash on out-of-namespace symref Message-ID: In-Reply-To: Junio C Hamano writes: > "Troels Thomsen" 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.