From: Jeff King Date: Fri, 17 Oct 2025 07:09:12 GMT Subject: Re: t7528-signed-commit-ssh.sh fails due to ssh-agent fails to start with ENAMETOOLONG Message-ID: <20251017070912.GA4068463@coredump.intra.peff.net> In-Reply-To: <87o6q6nux7.fsf@gmail.com> On Thu, Oct 16, 2025 at 07:06:44PM -0700, Collin Funk wrote: > Xi Ruoyao 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. Git's internal unix-domain socket code checks the name against sizeof(sa->sun_path) and will temporarily chdir into the surrounding directory and use a relative path if necessary. The errors above aren't from Git, so presumably they're from ssh-agent itself, which is pulling the name from the $HOME we set in test-lib.sh. So probably we could use the same trick like: diff --git a/t/t7528-signed-commit-ssh.sh b/t/t7528-signed-commit-ssh.sh index 0f887a3ebe..214908b2eb 100755 --- a/t/t7528-signed-commit-ssh.sh +++ b/t/t7528-signed-commit-ssh.sh @@ -82,7 +82,7 @@ test_expect_success GPGSSH 'create signed commits' ' test_expect_success GPGSSH 'sign commits using literal public keys with ssh-agent' ' test_when_finished "test_unconfig commit.gpgsign" && test_config gpg.format ssh && - eval $(ssh-agent) && + eval $(ssh-agent -a ./agent.sock) && test_when_finished "kill ${SSH_AGENT_PID}" && test_when_finished "test_unconfig user.signingkey" && mkdir tmpdir && But that does mean that ssh-agent will produce: SSH_AUTH_SOCK=./agent.sock which is only valid from that directory. If we wanted to protect ourselves, we'd have to further set SSH_AUTH_SOCK to the full $PWD/agent.sock. But I'd guess that just pushes the error onto ssh-add trying to connect later with the full pathname. Using the relative path does seem to work for me, at least insofar as: ./t7528-signed-commit-ssh.sh --run=1-2 -v -x -i \ --root=/tmp/holy-smokes-this-is-a-really-long-pathname triggers the length issue before but not after. 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. -Peff