[REPOST PATCH xauth] Don't crash when running past the end of the chain

[Egbert Eich]

On Thu, Sep 19, 2013 at 10:52:52AM -0400, Mouse wrote:
> >>>> [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.
> 

Ok, what you are requesting is a change in behavior of xcb and
to bring both in sync to xauth (and xhost) also and according to
what you said above you also agree with this goal.
This is different from the issue I'm trying to solve here. I'm
trying to bring xauth in sync with what xcb (partly thru libXau)
does. I do believe changing xauth is less critical than changing
xcb in the sense that the changes will have fewer side effects.

I therefore suggest to bring xauth in sync with libxcb now and
discuss the other issue independently - maybe even on the xcb ML.
If a conclusion is made make the appropriate changes to xcb and
keep in mind to keep xauth in sync.

Cheers,
	Egbert.