Earlier versions crash while running tests.
This patch is part of a series of fixes to make wolfSSL AES-GCM support
work together with libssh2.
Possibly related is this wolfSSL bugfix patch, released in v5.4.0:
https://github.com/wolfSSL/wolfssl/pull/5205fb3c611275
"Fix another AES-GCM EVP control command issue"
Ref: #1020
Ref: #1299
Cherry-picked from #1407Closes#1411
Replace hard-coded crypto backends and rely on `LIBSSH2_GCM` macro
to decide whether to run AES-GCM tests.
Without this, build attempted to run AES-GCM tests (and failed)
for crypto backends that have conditional support for this feature, e.g.
wolfSSL without the necessary features built-in
(as in before Homewbrew wolfssl 5.7.0_1, or OpenSSL v1.1.0 and older).
This patch is part of a series of fixes to make wolfSSL AES-GCM support
work together with libssh2.
Cherry-picked from #1407Closes#1410
Turns out these tests:
```
31 - test_read-aes128-gcm@openssh.com (Failed)
36 - test_read-aes256-gcm@openssh.com (Failed)
```
were failing because AES-GCM wasn't enabled in libssh2. This in turn
happened because the `WOLFSSL_AESGCM_STREAM` macro wasn't enabled while
building wolfSSL. Which happened because this macro isn't enabled by
any CMake-level wolfSSL option. Passing it as `CPPFLAGS` fixes it.
This allows enabling tests with wolfSSL 5.7.0.
Follow-up to d4cea53f53#1408Closes#1409
After this patch it's possible to run tests with wolfSSL 5.7.0.
wolfSSL 5.7.0 fixes this bug that affects open issues #1020 and #1299:
https://github.com/wolfSSL/wolfssl/pull/7143
`-DWOLFSSL_OPENSSLALL=ON` is necessary for `wolfSSL_FIPS_mode()`
Closes#1408
- make curl downloads less verbose.
- fix cmake warning:
```
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
```
Ref: https://github.com/libssh2/libssh2/actions/runs/9509866494/job/26213472410#step:5:32
The `libssh2_sftp_unlink` macro was implicitly casting the `size_t`
returned by `strlen` to the `unsigned int` type expected by
`libssh2_sftp_unlink_ex`.
This fix adds an explicit cast to match similar macro definitions in
the same file (e.g. `libssh2_sftp_rename`, `libssh2_sftp_mkdir`).
Closes#1406
- dump cmake error log on configure failure. (for cmake 3.26 and newer)
- dump `config.log` on autotools configure failure.
- convert specs filename to Windows format before passing to CMake.
- add missing quotes.
Closes#1403
For better build performance. Dependency tracking causes a build
overhead while compiling to help a subsequent build, but in CI there is
never one and the extra work is discarded.
Closes#1396
A compile-time failure is preferred over an unexpected one at
runtime.
The problem is silenced with a macro in CI and this macro will have
to be added to more platforms when mbedTLS v3.6.0 reaches them.
Follow-up to 2e4c5ec462#1349Closes#1393
autotools lib detection routine failed to extend LDFLAGS for each
detection. This could cause successful detection of a dependency, but
later failing to use it. This did not cause an issue as long as all
dependencies lived under the same prefix, but started breaking on macOS
ARM + Homebrew where this was no longer true for mbedTLS and zlib in
particular.
Follow-up to 844115393b#1381
Follow-up to ae2770de25#1377Closes#1384
In 1c3a03ebc3#493,
`LIBSSH2_DH_GEX_MAXGROUP` was introduced to specify
crypto-backend-specific modulus sizes. Unfortunately, the max size for
the wincng DH modulus was defined to 8192, probably because this is the
value most other backends support.
According to Microsoft documentation [1], `BCryptGenerateKeyPair`
currently only supports up to 4096-bit keys when the selected algorithm
is `BCRYPT_DH_ALGORITHM`. Requesting larger keys when calling
`BCryptGenerateKeyPair` in `_libssh2_dh_key_pair` always results in
`STATUS_INVALID_PARAMETER` being returned and ultimately key exchange
failing.
When attempting to connect to any server that offers 8192 bit DH, this
causes key exchange to always fail when using the wincng backend.
Reducing `LIBSSH2_DH_GEX_MAXGROUP` to 4096 fixes the issue.
[1] https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgeneratekeypairCloses#1372
Use an ugly workaround to silence `-Wsign-conversion` warnings triggered
by the internals of `FD_SET()`/`FD_ISSET()` macros. They've been showing
up in OmniOS CI builds when compiling `example` programs. They also have
been seen with older Cygwin and other envs and configurations.
Also scope two related variables in examples.
E.g.:
```
../../example/direct_tcpip.c:251:9: warning: conversion to 'long unsigned int' from 'libssh2_socket_t' {aka 'int'} may change the sign of the result [-Wsign-conversion]
251 | FD_SET(forwardsock, &fds);
| ^~~~~~
../../example/direct_tcpip.c:251:9: warning: conversion to 'long unsigned int' from 'libssh2_socket_t' {aka 'int'} may change the sign of the result [-Wsign-conversion]
../../example/direct_tcpip.c:251:9: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
../../example/direct_tcpip.c:251:9: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
../../example/direct_tcpip.c:259:18: warning: conversion to 'long unsigned int' from 'libssh2_socket_t' {aka 'int'} may change the sign of the result [-Wsign-conversion]
259 | if(rc && FD_ISSET(forwardsock, &fds)) {
| ^~~~~~~~
../../example/direct_tcpip.c:259:18: warning: conversion to 'long unsigned int' from 'libssh2_socket_t' {aka 'int'} may change the sign of the result [-Wsign-conversion]
../../example/direct_tcpip.c:259:18: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
```
Ref: https://github.com/libssh2/libssh2/actions/runs/8854199687/job/24316762831#step:3:2020Closes#1379
Use `AM_CFLAGS` to pass custom, per-target C flags. This replaces using
`CFLAGS` which triggered this warning when running `autoreconf -fi`:
```
tests/Makefile.am:8: warning: 'CFLAGS' is a user variable, you should not override it;
tests/Makefile.am:8: use 'AM_CFLAGS' instead
```
(Only for `tests`, even though `example` and `src` also used this
method. The warning is also missing from curl, that also uses
`CFLAGS`.)
Follow-up to 3ec53f3ea2#1286Closes#1378
- add `./configure` option `--enable-ecdsa-wincng`
- add WinCNG autotools jobs to GHA.
- enable WinCNG ECDSA in some GHA jobs (both CMake and autotools).
Follow-up to 3e72343737#1315Closes#1368
The WinCNG backend currently only supports DSA and RSA. This PR
adds ECDSA support for host and user authentication.
* Disable WinCNG ECDSA support by default to maintain backward
compatibility for projects that target versions below Windows 10.
* Add cmake option `ENABLE_ECDSA_WINCNG` to guard ECDSA support.
* Update AppVeyor job matrix to only enable ECDSA on Server 2016+
- Build scripts must be executed by the os/400 shell (sh), not bash which
is a PASE program: The `-ot` non-POSIX test extension works in os/400 as
well. Ref: https://github.com/libssh2/libssh2/pull/1364#issue-2241646754
- Drop/fixup mods trying to make some syntax highlighters happier.
Follow-up to c6625707b9#1358
Assisted-by: Patrick Monnerat
Closes#1364Closes#1366
- use `$()` instead of backticks, and re-arrange double-quotes inside.
- add missing `|| exit 1` to `cd` calls. (could be dropped by using `set -eu`.)
- add `-n` to a few `if`s.
- shorten redirections by using `{} >` (as shellcheck recommended).
- silence warnings where variables were detected as unused (SC2034).
- a couple misc updates to silence warnings.
- switch to bash shebang for `-ot` feature.
- split two lines to unbreak syntax highlighting in my editor. (`$(expr \`, `$(dirname \`)
Also enable CI checks for OS/400 shell scripts.
Ref: d88b9bcdafCloses#1358
