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

[Mouse]

>>>> [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		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B