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>
Another Clang 16ish fix (which makes -Wimplicit-function-declaration
an error by default). github PR#355.
See: 2efd71da49b9cfeab7987058cf5919e473ff466b
See: be19763532
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.
Factor out the arc4random seeding into its own file and change the
interface to match getentropy. Use native getentropy if available.
This will make it easier to resync OpenBSD changes to arc4random.
Prompted by bz#3467, ok djm@.
We added a check in Makefile to catch the case where configure needs to
be rebuilt, however this did not happen until a build was attempted in
which case all of the work done by configure was wasted. Move this check
to the start of configure to catch it as early as possible. ok djm@
Some of our binaries (eg sftp, sftp-server, scp) do not interact with
the channels code and thus do use libraries such as zlib and libcrypto
although they are linked with them. This adds a CHANNELLIBS and starts
by moving zlib into it, which means the aformentioned binaries are no
longer linked against zlib. ok djm@
We have some compatibility hacks that were added to support OpenSSL
versions that do not support AES CTR mode. Since that time, however,
the minimum OpenSSL version that we support has moved to 1.0.1 which
*does* have CTR, so this is no longer needed. ok djm@
We have some compatibility hacks that were added to support OpenSSL
versions that do not support AES GCM mode. Since that time, however,
the minimum OpenSSL version that we support has moved to 1.0.1 which
*does* have GCM, so this is no longer needed. ok djm@
Configure goes to some lengths to pick crypt() from either libcrypt
or OpenSSL's libcrypto because they can more or less featureful (eg
supporting md5-style passwords).
OpenSSL removed its crypt() interface in 2002:
https://github.com/openssl/openssl/commit/69deec58 so these hijinks
should no longer be necessary. This also only links sshd with libcrypt
which is the only thing that needs it. ok djm@