Running 'startx' on a machine named 'myhost' (aarch64), with a sub-directory named 'myhost' in my home directory:  X starts very slowly, and I see the message:

	xauth:  timeout in locking authority file /home/john/.Xauthority

Here's what happens: the 'startx' script calls 'xauth list' in a loop (line 199) and the first call crashes after receiving SIG_SEGV; this leaves its lock files in place, and the next instance of xauth times out waiting for them to go away.

I think I've traced the reason for 'xauth list' crashing: my .Xauthority file contains a line like this:

	myhost:0 MIT-MAGIC-COOKIE-1 <some value>

and while processing this for printing, there's some code in parsedpy.c (line 178) that does this:

	if (0 == stat(path, &sbuf))
		family = FamilyLocal;

and this test succeeds because 'myhost' is the name of a valid file (actually a directory)

Then later on in gethost.c we have:

	switch (family) {
		case FamilyLocal: /* hostname/unix:0 */
			...
			if (0 == stat(path, &sbuf))
				is_path_to_socket = 1;
			...
			if (is_path_to_socket)
				strncpy(buf, strrchr(fulldpyname, '/') + 1, sizeof(buf));

But there is no '/' in the name, so we end up passing a null pointer to strncpy(), which crashes the whole program.

My testing confirms this bug still applies to xauth-1:1.1-1 in Bullseye,
as the status graphic indicates.

Fixed upstream in xauth-1.1.1.  I hope that version can be
packaged in time for Bookworm -- it includes a number of
subtle but important improvements.

Looking at the upstream repo at
https://gitlab.freedesktop.org/alanc/xauth
the fix for this particular issue was applied in commit c2811c95
by Alex Gendin on Sep 26, 2020.

Triggering the bug was also made less likely with commit 18a3c3a7
by Dr. Tilmann Bubeck on Aug 20, 2020, but that change seems
incomplete in my testing.  I attach a two-line patch that
gives correct output when a file or directory in $PWD happens
to have the same name as $(hostname).

Example, starting with the buggy Debian Bullseye xauth-1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth list $(hostname -f):0
Segmentation fault
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
57941079 -rw------- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c
57941079 -rw------- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l
guest@redacted:~/empty$

Then xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
xauth-1.1.1: (argv):1:  bad display name "redacted.localdomain:0" in "list" command
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

And finally my patched xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

  - Larry