I can't find a reliable way to detect the features the ML-KEM code
requires in configure. Give up for now and use VLA support (that we
can detect) as a proxy for "old compiler" and turn off ML-KEM if
it isn't supported.
The ML-KEM implementation we uses need the compiler to support
C99-style named struct initialisers (e.g foo = {.bar = 1}). We
still support (barely) building OpenSSH with older compilers, so
add a configure test for this.
compile-time flag now than an IANA codepoint has been assigned for the
algorithm.
Add mlkem768x25519-sha256 in 2nd KexAlgorithms preference slot.
ok markus@
OpenBSD-Commit-ID: 9f50a0fae7d7ae8b27fcca11f8dc6f979207451a
ML-KEM768 with ECDH/X25519 from the Internet-draft:
https://datatracker.ietf.org/doc/html/draft-kampanakis-curdle-ssh-pq-ke-03
This is based on previous patches from markus@ but adapted to use the
final FIPS203 standard ML-KEM using a formally-verified implementation
from libcrux.
Note this key exchange method is still a draft and thus subject to
change. It is therefore disabled by default; set MLKEM=yes to build it.
We're making it available now to make it easy for other SSH
implementations to test against it.
ok markus@ deraadt@
OpenBSD-Commit-ID: 02a8730a570b63fa8acd9913ec66353735dea42c
If the following functions are available,
add an additional check if users are allowed to login imposed by login class.
* auth_hostok(3)
* auth_timeok(3)
These functions are implemented on FreeBSD.
Like Linux, proper _SOURCE macros need to be set to get declarations of
various standard functions, notably setres*id. Now that Debian is using
-Werror=implicit-function-declaration this is really required. While at
it, define other _SOURCE macros like on GNU/Linux, since GNU/Hurd uses
the same glibc.
markus@
(yes, I know this expands to "the Digitial Signature Algorithm
signature algorithm)
OpenBSD-Commit-ID: 961ef594e46dd2dcade8dd5721fa565cee79ffed
OpenSSL has moved to 3.4 which we don't currently accept. Based on
the OpenSSL versioning policy[0] it looks like all of the 3.x versions
should work with OpenSSH, so remove the distinction in configure and
accept all of them.
[0] https://openssl.org/policies/general/versioning-policy.html
If --enable/disable-dsa-keys is not specified, set based on what OpenSSL
supports. If specified as enabled, but not supported by OpenSSL error
out. ok djm@
... since it seems to be problematic with several different versions of
clang. Only use -fzero-call-used-regs=used which is less
problematic, except with Apple's clang where we don't use it at all.
bz#3629, ok djm@
Apple's versions of clang have version numbers that do not match the
corresponding upstream clang versions. Unfortunately, they do still
have the clang-15 zero-call-used-regs=all bug, so for now use the value
that doesn't result in segfaults. We could allowlist future versions
that are known to work. bz#3584 (and probably also our github CI
failures).
It's possible to install an OpenSSL in a path not in the system's
default library search path. OpenSSH can still use this (eg if you
specify an rpath) but the openssl binary there may not work. If one is
available on the system path just use that.
clang 15 seems to have a problem with -fzero-call-used-reg=all which
causes spurious "incorrect signature" failures with ED25519. On those
versions, use -fzero-call-used-regs=used instead. (We may add exceptions
later if specific versions prove to be OK). Also move the GCC version
check to match.
Initial investigation by Daniel Pouzzner (douzzer at mega nu), workaround
suggested by Bill Wendling (morbo at google com). bz#3475, ok djm@
On some very old platforms, sys/stat.h needs sys/types.h, however
autoconf 2.71's AC_CHECK_INCLUDES_DEFAULT checks for them in the
opposite order, which in combination with modern autoconf's
"present but cannot be compiled" behaviour causes it to not be
detected.
glibc has the prototypes for setresuid and setresgid behind _GNU_SOURCE,
and clang 16 will error out on implicit function definitions, so add
_GNU_SOURCE and the required headers to the configure checks. From
sam at @gentoo.org via bz#3497.
Clang 16 now warns on this and it'll be removed in C23, so let's
just be future proof. It also reduces noise when doing general
Clang 16 porting work (which is a big job as it is). github PR#355.
Signed-off-by: Sam James <sam@gentoo.org>
Clang 15 -Wimplicit-int defaults to an error in C99 mode and above.
A handful of tests have "main(..." and not "int main(..." which caused
the tests to produce incorrect results.