SSH_TIME_T_MAX for this, so move from misc.c to misc.h so it's available.
Fixes a Coverity warning for 64bit time_t safety, ok djm@
OpenBSD-Commit-ID: c69c4c3152cdaab953706db4ccf4d5fd682f7d8d
This was due to the sshd logs being written to the wrong log file.
While there, make save_debug_logs less verbose, write the name of the
tarball to regress.log and use $SUDO to remove the old symlinks (which
shouldn't be needed, but won't hurt). Initial problem spotted by anton@.
OpenBSD-Regress-ID: 9c44fb9cd418e6ff31165e7a6c1f9f11a6d19f5b
In the case of an fprintf failure we would not call fclose which would
leak the FILE pointer. While we're there, try to clean up the temp file
on failure. Spotted by Coverity, ok djm@
OpenBSD-Commit-ID: 73c7ccc5d4fcc235f54c6b20767a2815408525ef
before creating new ones. In -portable some platforms don't like
overwriting existing symlinks.
OpenBSD-Regress-ID: 7e7ddc0beb73e945e1c4c58d51c8a125b518120f
Previously we would log to ssh.log and sshd.log, but that is insufficient
for tests that have more than one concurent ssh/sshd.
Instead, we'll log to separate datestamped files in a $OBJ/log/ and
leave a symlink at the previous location pointing at the most recent
instance with an entry in regress.log showing which files were created
at each point. This should be sufficient to reconstruct what happened
even for tests that use multiple instances of each program. If the test
fails, tar up all of the logs for later analysis.
This will let us also capture the output from some of the other tools
which was previously sent to /dev/null although most of those will be
in future commits.
OpenBSD-Regress-ID: f802aa9e7fa51d1a01225c05fb0412d015c33e24
Since we don't use getopt_long() nothing outside the getopt()
implementation itself uses this structure, so move it into the
source to remove it from visibility and clashes with libc's
ok dtucker@
POSIX and ANSI C require that applications call fseek or similar between
read and writing to a RW file. OpenBSD doesn't enforce this, but some
(System V derived) platforms need this to prevent it from writing a
spurious extra byte (in this case, a newline). ok djm@ deraadt@
OpenBSD-Commit-ID: 33e680dcd8110582a93a40a8491024e961f45137
to set this was removed in OpenSSH 7.7 when support for SSH implementations
dating back to before RFC standardization were removed. "burn it all" djm@
OpenBSD-Commit-ID: 6330935fbe23dd00be79891505e06d1ffdac7cda
was previously set for OpenSSH 2.3 (released in 2000) but this check was
removed in OpenSSH 7.7 (2018). ok djm@ deraadt@
OpenBSD-Commit-ID: 326426ea328707fc9e83305291ab135c87f678af
since it's only applicable to SSH1 and thus no longer used. ok markus@
"kill it with fire" djm@
OpenBSD-Commit-ID: ea13318b1937795d9db4790d3ce0a6ed01584dab
Check if flags to mmap and madvise are defined before using them.
Should fix problems building on older Linux systems that don't have
these. bz#3537, with & ok djm@.
-Ohashalg=sha1|sha256 when outputting SSHFP fingerprints to allow algorithm
selection. bz3493 ok dtucker@
OpenBSD-Commit-ID: e6e07fe21318a873bd877f333e189eb963a11b3d
effective configuration without attempting to load private keys and perform
other checks. This allows usage of the option before keys have been
generated.
bz3460 feedback/ok dtucker@
OpenBSD-Commit-ID: 774504f629023fc25a559ab1d95401adb3a7fb29
so the recently-added ones will result in the test not cleaning up
after itself. Patch from cjwatson at debian.org vi bz#3536.
OpenBSD-Regress-ID: 1fc8283568f5bf2f918517c2c1e778072cf61b1a
Linux mmap(2) and madvise(2) syscalls support quite a number of funky
flags that we don't expect that sshd/libc will ever need. We can
exclude this kernel attack surface by filtering the mmap(2) flags
and the madvise(2) advice arguments.
Similarly, the sandboxed process in sshd is a single-threaded program
that does not use shared memory for synchronisation or communication.
Therefore, there should be no reason for the advanced priority
inheritance futex(2) operations to be necessary. These can also be
excluded.
Motivated by Jann Horn pointing out that there have been kernel bugs
in nearby Linux kernel code, e.g. CVE-2020-29368, CVE-2020-29374 and
CVE-2022-42703.
Feedback Jann Horn, ok dtucker@