>>>> [PATCH xauth] Look for FamilyLocal if inet or inet6 address is loopback >> If the address came from resolving a name, as in "xhost +localhost", >> then I like this. But if the address was specified directly, as in >> "xhost +::1", then I'd go so far as to say that adding FamilyLocal, >> or, worse, replacing it with FamilyLocal, is a bug. > This is a patch to xauth, not xhost.
Right, my mistake. But the same remarks apply there; if I xauth localhost, I want to set/get FamilyLocal entries, but if I xauth 127.0.0.1, I want just 127.0.0.1, no FamilyLocal. > Also you didn't see the full comment, only the subject. The full > comment described the reasoning behind the change which I believe is > still valid: > libxcb uses FamilyLocal authorization if the host name or IP in > the display string is from the loopback device. This patch adds > the same behavior to xauth. > This fixes a long standing problem that for ssh tunneled > connections a display variable of the form: localhost:<N>.<M> > leads to correct authorization when an X client is started but > "xauth list $DISPLAY" returns nothing. I do agree that xauth and libxcb should use the same rules; I just don't think the rules outlined for libxcb (and which this patch adds to xauth) are the right ones. That is, I'd make similar remarks about libxcb: it should include FamilyLocal for localhost but not for 127.0.0.1 or ::1. (I'm not sure what I think the right thing is for other names that resolve to 127.0.0.1 and/or ::1, or for names that resolve to one/both of those but also at least one other address.) > I can repost the patches here, but [...] No, not relevant; it's the behaviour I'm talking about, not the implementation of it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel