Add a new function `libssh2_sftp_posix_rename_ex()` and
`libssh2_sftp_posix_rename()`, which implement
the posix-rename@openssh.com extension.
If the server does not support this extension, the function returns
`LIBSSH2_FX_OP_UNSUPPORTED` and it's up to the user to recover, possibly
by calling `libssh2_sftp_rename()`.
Co-authored-by: Viktor Szakats (bump to size_t)
Closes#1386
Add workaround for the wolfSSL `EVP_Cipher(*p, NULL, NULL, 0)` bug to
make libssh2 work with wolfSSL v5.6.0 and older.
wolfSSL fixed this issue in v5.7.0:
https://github.com/wolfSSL/wolfssl/pull/7143b0de0a1c95
Without our local workaround:
- v5.3.0 and older fail most tests:
Ref: https://github.com/libssh2/libssh2/actions/runs/9646827522/job/26604211476#step:17:1263
- v5.4.0, v5.5.x, v5.6.0 fail these:
```
29 - test_read-aes128-cbc (Failed)
30 - test_read-aes128-ctr (Failed)
32 - test_read-aes192-cbc (Failed)
33 - test_read-aes192-ctr (Failed)
34 - test_read-aes256-cbc (Failed)
35 - test_read-aes256-ctr (Failed)
```
Ref: https://github.com/libssh2/libssh2/actions/runs/9646827522/job/26604233819#step:17:978
Oddly enough the workaround breaks OpenSSL tests, so only enable it for
the affected wolfSSL versions.
Also add new build-from-source wolfSSL CI job to test the new codepath.
wolfSSL has a build bug where `wolfssl/options.h` and
`wolfssl/version.h` are not copied to the `install` destination with
autotools. With CMake it has a different bug where `wolfcrypt/sp_int.h`
is not copied (with v5.4.0). And another with CMake where `FIPS_mode()`
remains missing (with v5.6.0 and earlier.)
Therefore use CMake with v5.5.4 and a workaround for `FIPS_mode()`.
Another option is autotools with v5.4.0 and a workaround for `install`,
but CMake builds quicker.
Regression-from 3c953c05d6#797Fixes#1020Fixes#1299
Assisted-by: Michael Buckley via #1394Closes#1394 (another attempt to fix the mentioned wolfSSL bug)
Closes#1407
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
