{"thread":{"id":"64371","subject":"[PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer","startedAt":"2025-10-23T07:15:12Z","lastAt":"2025-10-23T13:34:47Z","messageCount":4,"participants":["Patrick Steinhardt","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"529467","messageId":"20251023-b4-pks-t7528-ssh-agent-socket-name-too-long-v1-1-f15eeec199f3@pks.im","threadId":"64371","inReplyTo":null,"subject":"[PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-23T07:14:59Z","receivedAt":"2025-10-23T07:15:12Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"In t7528 we spawn an SSH agent to verify that we can sign a commit via\nit. This test has started to fail on some machines:\n\n +++ ssh-agent\n unix_listener_tmp: path \"/home/pks/Development/git/build/test-output/trash directory.t7528-signed-commit-ssh/.ssh/agent/s.UTulegefEg.agent.UrPHumMXPq\" too long for Unix domain socket\n main: Couldn't prepare agent socket\n\nAs it turns out this is caused by a change in OpenSSH 10.1 [1]:\n\n * ssh-agent(1), sshd(8): move agent listener sockets from /tmp to\n under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets\n in sshd(8).\n\nInstead of creating the socket in \"/tmp\", OpenSSH now creates the socket\nin our home directory. And as the home directory gets modified to be\nlocated in our test output directory we end up with paths that are\nsomewhat long. But Linux has a rather short limit of 108 characters for\nsocket paths, and other systems have even lower limits, so it is very\neasy now to exceed the limit and run into the above error.\n\nWork around the issue by using `ssh-agent -T`, which instructs it to\nuse the old behaviour and create the socket in \"/tmp\" again. This switch\nhas only been introduced with 10.1 though, so for older versions we have\nto fall back to not using it. That's fine though, as older versions know\nto put the socket into \"/tmp\" already.\n\nAn alternative approach would be to abbreviate the socket name itself so\nthat we create it as e.g. \"sshsock\" in the trash directory. But taking\nthe above example we'd still end up with a path that is 91 characters\nlong. So we wouldn't really have a lot of headroom, and it is quite\nlikely that some developers would see the issue on their machines.\n\n[1]: https://www.openssh.com/txt/release-10.1\n\nReported-by: Xi Ruoyao \nSuggested-by: brian m. carlson \nHelped-by: Jeff King \nHelped-by: Lauri Tirkkonen \nSigned-off-by: Patrick Steinhardt \n---\nHi,\n\nI now started to see the issue reported in [1] on my own machine and in\nour CI. I couldn't find a patch yet, so I decided to take the discussion\nthat happened in this thread and cast it into a patch to fix this.\n\nAs I am merely taking what others have debugged and agreed on I went a\nbit overboard with giving credit.\n\nThanks!\n\nPatrick\n\n[1]: <4e2952e512afc780b621d2c153b3e6e4eb7ed89a.camel@xry111.site>\n---\n t/t7528-signed-commit-ssh.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/t7528-signed-commit-ssh.sh b/t/t7528-signed-commit-ssh.sh\nindex 0f887a3ebee..b50306b9b39 100755\n--- a/t/t7528-signed-commit-ssh.sh\n+++ b/t/t7528-signed-commit-ssh.sh\n@@ -82,7 +82,7 @@ test_expect_success GPGSSH 'create signed commits' '\n test_expect_success GPGSSH 'sign commits using literal public keys with ssh-agent' '\n \ttest_when_finished \"test_unconfig commit.gpgsign\" &&\n \ttest_config gpg.format ssh &&\n-\teval $(ssh-agent) &&\n+\teval $(ssh-agent -T || ssh-agent) &&\n \ttest_when_finished \"kill ${SSH_AGENT_PID}\" &&\n \ttest_when_finished \"test_unconfig user.signingkey\" &&\n \tmkdir tmpdir &&\n\n---\nbase-commit: c54a18ef67e59cdbcd77d6294916d42c98c62d1d\nchange-id: 20251023-b4-pks-t7528-ssh-agent-socket-name-too-long-69fad53b67ea\n\n"},{"id":"529498","messageId":"20251023124320.GA1163932@coredump.intra.peff.net","threadId":"64371","inReplyTo":"20251023-b4-pks-t7528-ssh-agent-socket-name-too-long-v1-1-f15eeec199f3@pks.im","subject":"Re: [PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-23T12:43:20Z","receivedAt":"2025-10-23T12:43:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 23, 2025 at 09:14:59AM +0200, Patrick Steinhardt wrote:\n\n> As it turns out this is caused by a change in OpenSSH 10.1 [1]:\n> \n> * ssh-agent(1), sshd(8): move agent listener sockets from /tmp to\n> under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets\n> in sshd(8).\n> \n> Instead of creating the socket in \"/tmp\", OpenSSH now creates the socket\n> in our home directory. And as the home directory gets modified to be\n> located in our test output directory we end up with paths that are\n> somewhat long. But Linux has a rather short limit of 108 characters for\n> socket paths, and other systems have even lower limits, so it is very\n> easy now to exceed the limit and run into the above error.\n\nThere's a secondary issue, too: even if the path is short enough, the\nspace in \"trash directory\" of the path will break the shell eval. That's\nrelevant below.\n\n> Work around the issue by using `ssh-agent -T`, which instructs it to\n> use the old behaviour and create the socket in \"/tmp\" again. This switch\n> has only been introduced with 10.1 though, so for older versions we have\n> to fall back to not using it. That's fine though, as older versions know\n> to put the socket into \"/tmp\" already.\n\nOK. I think this is an improvement over the status quo, though it leaves\na lot of loose ends, like:\n\n - what happens if \"ssh-agent\" does not exist at all; we do not notice\n the error because the eval succeeds anyway (with blank input)\n\n - one reason we did not notice this immediately is that the failure\n mode is to fall back to using the user's SSH_AUTH_SOCK variable if\n set (i.e., their real agent with their keys in it!). We should\n perhaps be clearing that variable in test-lib.sh.\n\nBut those are not really new issues, and I'm OK with just un-breaking\nthings in the most expedient way possible.\n\n> An alternative approach would be to abbreviate the socket name itself so\n> that we create it as e.g. \"sshsock\" in the trash directory. But taking\n> the above example we'd still end up with a path that is 91 characters\n> long. So we wouldn't really have a lot of headroom, and it is quite\n> likely that some developers would see the issue on their machines.\n\nI assume you mean here something like:\n\n ssh-agent \"$PWD/sshsock\"\n\nYeah, that is not buying us that much in terms of headroom. Plus it\nwould still run afoul of the space issue, since we know that $PWD will\nalways contain \"trash directory\".\n\nIf we are going to provide a fixed name, I think it would have to be a\ntrue relative path like:\n\n ssh-agent ./sshsock\n\nThat does work (and SSH_AUTH_SOCK contains the relative path), but is\nmaybe a bit of a booby trap waiting to spring on somebody who tries to\naccess the agent with a different current working directory.\n\n-Peff\n"},{"id":"529503","messageId":"aPoslANELg4V286u@pks.im","threadId":"64371","inReplyTo":"20251023124320.GA1163932@coredump.intra.peff.net","subject":"Re: [PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-23T13:24:36Z","receivedAt":"2025-10-23T13:24:44Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 23, 2025 at 08:43:20AM -0400, Jeff King wrote:\n> On Thu, Oct 23, 2025 at 09:14:59AM +0200, Patrick Steinhardt wrote:\n> \n> > As it turns out this is caused by a change in OpenSSH 10.1 [1]:\n> > \n> > * ssh-agent(1), sshd(8): move agent listener sockets from /tmp to\n> > under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets\n> > in sshd(8).\n> > \n> > Instead of creating the socket in \"/tmp\", OpenSSH now creates the socket\n> > in our home directory. And as the home directory gets modified to be\n> > located in our test output directory we end up with paths that are\n> > somewhat long. But Linux has a rather short limit of 108 characters for\n> > socket paths, and other systems have even lower limits, so it is very\n> > easy now to exceed the limit and run into the above error.\n> \n> There's a secondary issue, too: even if the path is short enough, the\n> space in \"trash directory\" of the path will break the shell eval. That's\n> relevant below.\n> \n> > Work around the issue by using `ssh-agent -T`, which instructs it to\n> > use the old behaviour and create the socket in \"/tmp\" again. This switch\n> > has only been introduced with 10.1 though, so for older versions we have\n> > to fall back to not using it. That's fine though, as older versions know\n> > to put the socket into \"/tmp\" already.\n> \n> OK. I think this is an improvement over the status quo, though it leaves\n> a lot of loose ends, like:\n> \n> - what happens if \"ssh-agent\" does not exist at all; we do not notice\n> the error because the eval succeeds anyway (with blank input)\n> \n> - one reason we did not notice this immediately is that the failure\n> mode is to fall back to using the user's SSH_AUTH_SOCK variable if\n> set (i.e., their real agent with their keys in it!). We should\n> perhaps be clearing that variable in test-lib.sh.\n> \n> But those are not really new issues, and I'm OK with just un-breaking\n> things in the most expedient way possible.\n\nYeah. I was wondering whether we should rather do:\n\n ( ssh-agent -F || ssh-agent ) >env &&\n source env\n\nssh-agent(1) knows to detach into the background unless told otherwise,\nso we should notice the failure and can then source the environment if\nit was successful. But I ultimately decided that for now I'd rather want\nto fix the fallout, we can still make it more robust after the fact.\n\n> > An alternative approach would be to abbreviate the socket name itself so\n> > that we create it as e.g. \"sshsock\" in the trash directory. But taking\n> > the above example we'd still end up with a path that is 91 characters\n> > long. So we wouldn't really have a lot of headroom, and it is quite\n> > likely that some developers would see the issue on their machines.\n> \n> I assume you mean here something like:\n> \n> ssh-agent \"$PWD/sshsock\"\n> \n> Yeah, that is not buying us that much in terms of headroom. Plus it\n> would still run afoul of the space issue, since we know that $PWD will\n> always contain \"trash directory\".\n\nYup, that was the idea, and yeah, I don't think it helps us much.\n\n> If we are going to provide a fixed name, I think it would have to be a\n> true relative path like:\n> \n> ssh-agent ./sshsock\n> \n> That does work (and SSH_AUTH_SOCK contains the relative path), but is\n> maybe a bit of a booby trap waiting to spring on somebody who tries to\n> access the agent with a different current working directory.\n\nMaybe. On the other hand we only have a single test anyway that uses\nssh-agent, so that's a problem for the future, I guess.\n\nIn any case, I'd say for now we should just fix the issue in the easiest\nway possible, and we can then follow up and make this more robust in a\nsubsequent patch series. WDYT?\n\nPatrick\n"},{"id":"529504","messageId":"20251023133445.GA1171431@coredump.intra.peff.net","threadId":"64371","inReplyTo":"aPoslANELg4V286u@pks.im","subject":"Re: [PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-23T13:34:45Z","receivedAt":"2025-10-23T13:34:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 23, 2025 at 03:24:36PM +0200, Patrick Steinhardt wrote:\n\n> In any case, I'd say for now we should just fix the issue in the easiest\n> way possible, and we can then follow up and make this more robust in a\n> subsequent patch series. WDYT?\n\nYeah, I'm OK with your patch as-is.\n\n-Peff\n"}]}