From djm at mindrot.org Wed Jul 1 10:02:13 2026 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Jul 2026 10:02:13 +1000 (AEST) Subject: Call for testing: OpenSSH 10.4 In-Reply-To: <79a107e6-93fe-45fc-af54-2d42a94554de@fs.ei.tum.de> References: <004bcf35-0716-14c7-dd03-ecaaf22a049d@mindrot.org> <79a107e6-93fe-45fc-af54-2d42a94554de@fs.ei.tum.de> Message-ID: <1ac633d0-0b73-b010-663a-1c291aec4569@mindrot.org> On Tue, 30 Jun 2026, Felix Fehlauer via openssh-unix-dev wrote: > Hi Damien, > > the (V_10_4) - Tracking bug for openssh-10.4 bz3942 [1] depends on bz3968 [2], > which is still open. > > Also the preliminary release notes you included mentions bz3954 [3], but this > bug is not mentioned in the tracking bug. > > Likewise, this tracking bug mentions bz3947 [4] and bz3952 [5], which are not > mentioned in the preliminary release notes. > > Is this intentional? No, but it also doesn't really matter. The release notes are intended to represent user-salient information, not exhaustively reproduce every bug or PR that we've worked on through the release cycle. > Besides this tests fail on Fedora Linux 44: > > failed copy of /bin/ls > cmp: EOF on ?/tmp/openssh/regress/copy? which is empty > corrupted copy of /bin/ls > failed local and remote forwarding Could you show some more context of the test run? It's hard to tell from this which test failed, or how far it progressed within the test before it failed. regress/failed*.log often has useful debugging information that can help identify the cause of failures. -d From loganaden at gmail.com Wed Jul 1 10:56:28 2026 From: loganaden at gmail.com (Loganaden Velvindron) Date: Wed, 1 Jul 2026 04:56:28 +0400 Subject: Call for testing: OpenSSH 10.4 In-Reply-To: References: <004bcf35-0716-14c7-dd03-ecaaf22a049d@mindrot.org> Message-ID: Man page PR for mldsa44-ed25519: https://github.com/openssh/openssh-portable/pull/696 From dtucker at dtucker.net Wed Jul 1 12:01:18 2026 From: dtucker at dtucker.net (Darren Tucker) Date: Wed, 1 Jul 2026 12:01:18 +1000 Subject: Call for testing: OpenSSH 10.4 In-Reply-To: <1ac633d0-0b73-b010-663a-1c291aec4569@mindrot.org> References: <004bcf35-0716-14c7-dd03-ecaaf22a049d@mindrot.org> <79a107e6-93fe-45fc-af54-2d42a94554de@fs.ei.tum.de> <1ac633d0-0b73-b010-663a-1c291aec4569@mindrot.org> Message-ID: On Wed, 1 Jul 2026 at 10:03, Damien Miller wrote: > On Tue, 30 Jun 2026, Felix Fehlauer via openssh-unix-dev wrote: [...] > > Besides this tests fail on Fedora Linux 44: > > > > failed copy of /bin/ls > > cmp: EOF on ?/tmp/openssh/regress/copy? which is empty > > corrupted copy of /bin/ls > > failed local and remote forwarding [...] > regress/failed*.log often has useful debugging information that can help > identify the cause of failures. I've run it here on Fedora 44 so it's possible for it to work. My guess is that something is preventing you from reading /bin/ls. maybe selinux? is /bin/ls world-readable? -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rapier at psc.edu Wed Jul 1 12:06:43 2026 From: rapier at psc.edu (Chris Rapier) Date: Tue, 30 Jun 2026 22:06:43 -0400 Subject: Empty Files Created by sftp Message-ID: <74e1b8c3-777d-41d1-b1d3-7416f7a9a571@psc.edu> I seem to have a found an odd situation. When the sftp-server is instantiated with "-P write" and I try putting a file I get the expected permission denied error. sftp> put xxhash.h Uploading xxhash.h to /tmp/xxhash.h xxhash.h 98% 255KB 238.9MB/s 00:00 ETA write remote "/tmp/xxhash.h": Permission denied However, I still get a file created at the destination with a file size of 0. rapier@:/tmp$ ls -l xxhash.h -rw-rw-r-- 1 rapier rapier 0 Jun 30 21:28 xxhash.h So it seems the file was opened but the write was disallowed. The main issue being that it consumes inodes and just generally clutters things up. This can be a real issue on large puts. I haven't tried this against 10.4 so you might have already resolved this. I'm pretty sure the issue is that the -P write will prevent the writes but it doesn't match on the open. If you do -P write,open then you can't actually do any reads. I'm digging into a fix but I don't like what I have at the moment. I don't think this would be a common scenario but it came up recently and thought I should bring it up. Chris From rapier at psc.edu Wed Jul 1 12:15:06 2026 From: rapier at psc.edu (Chris Rapier) Date: Tue, 30 Jun 2026 22:15:06 -0400 Subject: Empty Files Created by sftp In-Reply-To: <74e1b8c3-777d-41d1-b1d3-7416f7a9a571@psc.edu> References: <74e1b8c3-777d-41d1-b1d3-7416f7a9a571@psc.edu> Message-ID: <452ad1bb-6c76-4e37-99a3-f0da2234af35@psc.edu> Oh, I'm sure the correct solution is to just use -R but this just seemed weird to me. If it's expected behaviour that's fine. On 6/30/2026 22:06, Chris Rapier wrote: > I seem to have a found an odd situation. When the sftp-server is > instantiated with "-P write" and I try putting a file I get the expected > permission denied error. > > sftp> put xxhash.h > Uploading xxhash.h to /tmp/xxhash.h > xxhash.h ????????????? 98%? 255KB 238.9MB/s?? 00:00 ETA > write remote "/tmp/xxhash.h": Permission denied > > However, I still get a file created at the destination with a file size > of 0. > > rapier@:/tmp$ ls -l xxhash.h > -rw-rw-r-- 1 rapier rapier 0 Jun 30 21:28 xxhash.h > > So it seems the file was opened but the write was disallowed. The main > issue being that it consumes inodes and just generally clutters things > up. This can be a real issue on large puts. I haven't tried this against > 10.4 so you might have already resolved this. > > I'm pretty sure the issue is that the -P write will prevent the writes > but it doesn't match on the open. If you do -P write,open then you can't > actually do any reads. I'm digging into a fix but I don't like what I > have at the moment. I don't think this would be a common scenario but it > came up recently and thought I should bring it up. > > Chris From djm at mindrot.org Wed Jul 1 14:37:52 2026 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Jul 2026 14:37:52 +1000 (AEST) Subject: Empty Files Created by sftp In-Reply-To: <452ad1bb-6c76-4e37-99a3-f0da2234af35@psc.edu> References: <74e1b8c3-777d-41d1-b1d3-7416f7a9a571@psc.edu> <452ad1bb-6c76-4e37-99a3-f0da2234af35@psc.edu> Message-ID: <83fa6680-e956-3a3f-11cb-d45346882fb2@mindrot.org> On Tue, 30 Jun 2026, Chris Rapier wrote: > Oh, I'm sure the correct solution is to just use -R but this just seemed > weird to me. If it's expected behaviour that's fine. It's probably the client failing when it tries to do a SSH_FXP_FSTAT operation to obtain the file's metadata (length and modes). If you allow "open,write,fstat" then I think it's likely to work. -d From felix.fehlauer at fs.ei.tum.de Wed Jul 1 20:53:26 2026 From: felix.fehlauer at fs.ei.tum.de (Felix Fehlauer) Date: Wed, 1 Jul 2026 12:53:26 +0200 Subject: Call for testing: OpenSSH 10.4 In-Reply-To: References: <004bcf35-0716-14c7-dd03-ecaaf22a049d@mindrot.org> <79a107e6-93fe-45fc-af54-2d42a94554de@fs.ei.tum.de> <1ac633d0-0b73-b010-663a-1c291aec4569@mindrot.org> Message-ID: On 7/1/26 04:01, Darren Tucker wrote: > On Wed, 1 Jul 2026 at 10:03, Damien Miller wrote: >> On Tue, 30 Jun 2026, Felix Fehlauer via openssh-unix-dev wrote: > [...] >>> Besides this tests fail on Fedora Linux 44: >>> >>> failed copy of /bin/ls >>> cmp: EOF on ?/tmp/openssh/regress/copy? which is empty >>> corrupted copy of /bin/ls >>> failed local and remote forwarding > [...] >> regress/failed*.log often has useful debugging information that can help >> identify the cause of failures. The last lines of the make test output are: test -D forwarding test -R forwarding PermitRemoteOpen=any PermitRemoteOpen=none PermitRemoteOpen=explicit PermitRemoteOpen=disallowed ok dynamic forwarding run test forwarding.sh ... WARNING: Unsafe (group or world writable) directory permissions found: /tmp These could be abused to locally escalate privileges. If you are sure that this is not a risk (eg there are no other users), you can bypass this check by setting TEST_SSH_UNSAFE_PERMISSIONS=1 failed copy of /bin/ls cmp: EOF on ?/tmp/openssh/regress/copy? which is empty corrupted copy of /bin/ls failed local and remote forwarding make[1]: *** [Makefile:245: t-exec] Error 1 make[1]: Leaving directory '/tmp/openssh/regress' make: *** [Makefile:830: t-exec] Error 2 Re-running with TEST_SSH_UNSAFE_PERMISSIONS=1 (as there indeed is only one user) only makes this warning disappear, but the error remains. Executing the tests in a different directory also does not make a difference. I have attached the full regress/failed*.log. It contains the following lines that seem strange to me: debug1: kex_exchange_identification: banner line 0: UNKNOWN COMMAND kex_exchange_identification: Connection closed by remote host Connection closed by 127.0.0.1 port 3322 All the other log files referenced in these logs unfortunately don't exist. > I've run it here on Fedora 44 so it's possible for it to work. My > guess is that something is preventing you from reading /bin/ls. maybe > selinux? is /bin/ls world-readable? Yes, it is world-readable: -rwxr-xr-x. 1 root root 153400 Jun 11 02:00 /bin/ls I cannot find any SELinux denials. Thanks for the help! -------------- next part -------------- A non-text attachment was scrubbed... Name: failed-ssh.log Type: text/x-log Size: 5794 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: failed-sshd.log Type: text/x-log Size: 92 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: failed-regress.log Type: text/x-log Size: 3484 bytes Desc: not available URL: