Don't call OpenSSL_add_all_algorithms() unless OpenSSL actually
supports it.
Move all libcrypto initialisation to a single function, and call that
from seed_rng() that is called early in each tool's main().
Prompted by patch from Rosen Penev
If configure could not find a working OpenSSL installation it would
fall back to checking in /usr/local/ssl. This made sense back when
systems did not ship with OpenSSL, but most do and OpenSSL 1.1 doesn't
use that as a default any more. The fallback behaviour also meant
that if you pointed --with-ssl-dir at a specific directory and it
didn't work, it would silently use either the system libs or the ones
in /usr/local/ssl. If you want to use /usr/local/ssl you'll need to
pass configure --with-ssl-dir=/usr/local/ssl. ok djm@
Check for the existence of openssl version functions and use the ones
detected instead of trying to guess based on the int32 version
identifier. Fixes builds with LibreSSL.
Current impementions of the gcc spectre mitigation flags cause
miscompilations when combined with other flags and do not provide much
protection. Found by fweimer at redhat.com, ok djm@
Cygwin's latest 7.x GCC allows to specify -mfunction-return=thunk
as well as -mindirect-branch=thunk on the command line, albeit
producing invalid code, leading to an error at link stage.
The check in configure.ac only checks if the option is present,
but not if it produces valid code.
This patch fixes it by special-casing Cygwin. Another solution
may be to change these to linker checks.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Most people will 1) be using modern multi-factor authentication methods
like TOTP/OATH etc and 2) be getting support for multi-factor
authentication via PAM or BSD Auth.
Add getline for the benefit of platforms that don't have it. Sourced
from NetBSD (OpenBSD's implementation is a little too chummy with the
internals of FILE).
Since autoconf always uses $CC to link C programs, allowing users to
override LD caused mismatches between what LD_LINK_IFELSE thought worked
and what ld thought worked. If you do need to do this kind of thing you
need to set a compiler flag such as gcc's -fuse-ld in LDFLAGS.
On at least some revisions of AIX, strndup returns unterminated strings
under some conditions, apparently because strnlen returns incorrect
values in those cases. Disable both on AIX and use the replacements
from openbsd-compat. Fixes problem with ECDSA keys there, ok djm.
Currently seccomp_audit_arch is set to AUDIT_ARCH_MIPS64 or
AUDIT_ARCH_MIPSEL64 (depending on the endinness) when openssh is built
for MIPS64. However, that's only valid for n64 ABI. The right macros for
n32 ABI defined in seccomp.h are AUDIT_ARCH_MIPS64N32 and
AUDIT_ARCH_MIPSEL64N32, for big and little endian respectively.
Because of that an sshd built for MIPS64 n32 rejects connection attempts
and the output of strace reveals that the problem is related to seccomp
audit:
[pid 194] prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=57,
filter=0x555d5da0}) = 0
[pid 194] write(7, "\0\0\0]\0\0\0\5\0\0\0Ulist_hostkey_types: "..., 97) = ?
[pid 193] <... poll resumed> ) = 2 ([{fd=5, revents=POLLIN|POLLHUP},
{fd=6, revents=POLLHUP}])
[pid 194] +++ killed by SIGSYS +++
This patch fixes that problem by setting the right value to
seccomp_audit_arch taking into account the MIPS64 ABI.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Some compilers (gcc 2.9.53, 3.0 and probably others, see gcc bug #3481)
do not accept __attribute__ on function pointer prototype args. Check for
this and hide them if they're not accepted.
Configure assumes that if malloc(0) returns null then calloc(0,n)
also does. On some old platforms (SunOS4) malloc behaves as expected
(as determined by AC_FUNC_MALLOC) but calloc doesn't. Test for this
at configure time and activate the replacement function if found, plus
handle this case in rpl_calloc.
BindInterface required getifaddr and friends so disable if not available
(eg Solaris 10). We should be able to add support for some systems with
a bit more work but this gets the building again.
The code required to support it is quite invasive to the mainline
code that is synced with upstream and is an ongoing maintenance burden.
Both the hardware and software are literal museum pieces these days and
we could not find anyone still running OpenSSH on one.
