t7528-signed-commit-ssh.sh fails due to ssh-agent fails to start with ENAMETOOLONG

> When I test git-2.51.1 I hit a test failure in t7528-signed-commit-
> ssh.sh.  Running it with -v reveals:
>
> unix_listener_tmp: path "/home/xry111/sources/12.5/git-2.51.1/t/trash directory.t7528-signed-commit-ssh/.ssh/agent/s.fTyCxA5V6V.agent.dX2yNWQUX5" too long for Unix domain socket
> main: Couldn't prepare agent socket
>
> So this seems an issue in the test harness.  Is it possible to fix it?

> Xi Ruoyao <xry111@xry111.site> writes:
> 
> > When I test git-2.51.1 I hit a test failure in t7528-signed-commit-
> > ssh.sh.  Running it with -v reveals:
> >
> > unix_listener_tmp: path "/home/xry111/sources/12.5/git-2.51.1/t/trash directory.t7528-signed-commit-ssh/.ssh/agent/s.fTyCxA5V6V.agent.dX2yNWQUX5" too long for Unix domain socket
> > main: Couldn't prepare agent socket
> >
> > So this seems an issue in the test harness.  Is it possible to fix it?
> 
> Unix sockets have an unfortunate historical limit of ~100 characters on
> most systems. All the derivatives of 4.4BSD have a limit of 104
> characters. Linux has a limit of 108 characters [1]. AIX is nice and
> supports 1024 characters, but I assume you are not using that.
> 
> I guess this test can check for that error. I'll have a look.

> But looking at this test, there's something even more funky going on.
> Our $HOME will always have a space in it, because no matter where you
> set the root, we will create "trash directory.t7582..." to work in. But
> AFAICT, ssh-agent does not quote the path in its output. So for example:
> 
>   d='/tmp/has spaces'
>   mkdir "$d"
>   HOME=$d ssh-agent
> 
> will produce:
> 
>   SSH_AUTH_SOCK=/tmp/has spaces/.ssh/agent/s.IcPuGe26YY.agent.6PtD3uhM4O; export SSH_AUTH_SOCK;
> 
> which is nonsense to eval. And indeed, the "working" version of this
> test (without a really long root path) produces:
> 
>   ./t7528-signed-commit-ssh.sh: 1: eval: directory.t7528-signed-commit-ssh/.ssh/agent/s.IcPuGe26YY.agent.sOzoazWiDc: not found
> 
> I expected that would cause ssh-add to fail, since our SSH_AUTH_SOCK
> would point to truncated garbage, and we can't talk to the agent. But it
> doesn't even do that. The extra space turns that line from a variable
> assignment into a one-shot variable attached to a command that fails to
> run. And so we're left with the original SSH_AUTH_SOCK from the
> environment, the one in my real $HOME outside of the trash directory.
> Yikes!
> 
> If I unset SSH_AUTH_SOCK in my environment, then the test consistently
> fails. But I'm somewhat amazed that nobody has complained about this
> before. Surely somebody somewhere (especially CI!) is running t7528
> without SSH_AUTH_SOCK set in the environment. Which makes wonder if I'm
> missing something.

> > If I unset SSH_AUTH_SOCK in my environment, then the test consistently
> > fails. But I'm somewhat amazed that nobody has complained about this
> > before. Surely somebody somewhere (especially CI!) is running t7528
> > without SSH_AUTH_SOCK set in the environment. Which makes wonder if I'm
> > missing something.
> 
> I believe the issue surfaced only now because prior to OpenSSH 10.1,
> ssh-agent would put its socket in /tmp by default, not under $HOME. See
> https://www.openssh.com/txt/release-10.1

> On Fri, Oct 17, 2025 at 06:52:49PM +0900, Lauri Tirkkonen wrote:
> 
> > > If I unset SSH_AUTH_SOCK in my environment, then the test consistently
> > > fails. But I'm somewhat amazed that nobody has complained about this
> > > before. Surely somebody somewhere (especially CI!) is running t7528
> > > without SSH_AUTH_SOCK set in the environment. Which makes wonder if I'm
> > > missing something.
> > 
> > I believe the issue surfaced only now because prior to OpenSSH 10.1,
> > ssh-agent would put its socket in /tmp by default, not under $HOME. See
> > https://www.openssh.com/txt/release-10.1
> 
> Ah, of course. That explains it perfectly, thanks. So we're going to get
> lots more reports as people upgrade. :)

> > We saw this failure in CI on Alpine Linux and worked around by adding -T
> > to the ssh-agent invocation in this test, but I suppose that won't work
> > for earlier releases of OpenSSH.
> 
> Yeah. We could either do something like "ssh-agent -T || ssh-agent", or
> we could go with "ssh-agent -a" (which has been around since 2002, but
> does raise the potential relative-path issue).

> I had not had time to properly analyze it in order to say something more
> thoughtful than "this is broken", but I can confirm it breaks for me on
> Debian unstable:
> 
>   ERROR: ld.so: object 'libc_malloc_debug.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
>   ./t7528-signed-commit-ssh.sh: 1: eval: directory.t7528-signed-commit-ssh/.ssh/agent/s.5w4CQ2109U.agent.5l0ixCaX1S: not found
>   Agent pid 1429798
>   Could not add identity "/home/bmc/checkouts/git/t/trash directory.t7528-signed-commit-ssh/gpghome/ed25519_ssh_signing_key": agent refused operation
> 
> Note that OpenSSH in my case is broken because of the space in the
> home directory.  I've reported that to Debian and we'll see if it gets
> fixed.  (I did mention it breaks the Git testsuite in the hopes that
> improves the likelihood of getting it fixed.)

> > Yeah. We could either do something like "ssh-agent -T || ssh-agent", or
> > we could go with "ssh-agent -a" (which has been around since 2002, but
> > does raise the potential relative-path issue).
> 
> I think like `ssh-agent -T || ssh-agent` would be better because we know
> $HOME can be very long in our case, whereas $TMPDIR should not be
> excessive (since presumably it worked before and other services, such as
> tmux, place their sockets there).

> AFAICT, ssh-agent does not quote the path in its output. So for example:
>
>   d='/tmp/has spaces'
>   mkdir "$d"
>   HOME=$d ssh-agent
>
> will produce:
>
>   SSH_AUTH_SOCK=/tmp/has spaces/.ssh/agent/s.IcPuGe26YY.agent.6PtD3uhM4O; export SSH_AUTH_SOCK;
>
> which is nonsense to eval.

> I expected that would cause ssh-add to fail, since our SSH_AUTH_SOCK
> would point to truncated garbage, and we can't talk to the agent. But it
> doesn't even do that. The extra space turns that line from a variable
> assignment into a one-shot variable attached to a command that fails to
> run. And so we're left with the original SSH_AUTH_SOCK from the
> environment, the one in my real $HOME outside of the trash directory.
> Yikes!
>
> If I unset SSH_AUTH_SOCK in my environment, then the test consistently
> fails. But I'm somewhat amazed that nobody has complained about this
> before. Surely somebody somewhere (especially CI!) is running t7528
> without SSH_AUTH_SOCK set in the environment. Which makes wonder if I'm
> missing something.
>
> -Peff

> Jeff King <peff@peff.net> writes:
> 
> > AFAICT, ssh-agent does not quote the path in its output. So for example:
> >
> >   d='/tmp/has spaces'
> >   mkdir "$d"
> >   HOME=$d ssh-agent
> >
> > will produce:
> >
> >   SSH_AUTH_SOCK=/tmp/has spaces/.ssh/agent/s.IcPuGe26YY.agent.6PtD3uhM4O; export SSH_AUTH_SOCK;
> >
> > which is nonsense to eval.
> 
> So if $d were
> 
>     d='/tmp/has rm -rf in it'
> 
> would that produce some interesting side effect?