From: Jeff King <peff@peff.net>
Date: Sat, 18 Oct 2025 09:56:06 GMT
Subject: Re: t7528-signed-commit-ssh.sh fails due to ssh-agent fails to start with ENAMETOOLONG
Message-ID: <20251018095606.GF1060824@coredump.intra.peff.net>
In-Reply-To: <aPKZeqTK-tIcrfFB@fruit.crustytoothpaste.net>

On Fri, Oct 17, 2025 at 07:31:06PM +0000, brian m. carlson wrote:

> 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.)

Thanks, I saw your report and had nothing to add. I agree it would be
nice if ssh-agent shell-quoted the output. I don't think there should be
portability issues.

> > 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).

Yeah, I think "-T" would work fine. I just find it a bit hacky to assume
that a failure of "ssh-agent -T" is because of the "-T" option. We also
could do better at detecting errors in general. If you did not have
ssh-agent at all, then:

  eval $(ssh-agent) &&

will not fail the &&-chain since its exit code is eaten in the $()
substitution, and we eval an empty string. So arguably we should pull
this into a prereq or something that makes sure we can actually run
ssh-agent in the first place.

-Peff