... while throwing LIBSSH2_ERROR_EAGAIN out of session_startup()
If the session runs in blocking mode, LIBSSH2_ERROR_EAGAIN never reaches
the libssh2 API boundary and, in non-blocking mode, these messages are
suppressed by the condition in _libssh2_error_flags() anyway.
Closes#211
- New `LIBSSH2_DLL_SUFFIX` envvar will add a suffix to the generated
libssh2 dll name. Useful to add `-x64` to 64-bit builds so that
it can live in the same directory as the 32-bit one. By default
this is empty.
- New `LIBSSH2_DLL_A_SUFFIX` envvar to customize the suffix of the
generated import library (implib) for libssh2 .dll. It defaults
to `dll`, and it's useful to modify that to `.dll` to have the
standard naming scheme for mingw-built .dlls, i.e. `libssh2.dll.a`.
Ref: aaa16f8025
Closes https://github.com/libssh2/libssh2/pull/215
Allow to ovverride certain build tools, making it possible to
use LLVM/Clang to build libssh2. The default behavior is unchanged.
To build with clang (as offered by MSYS2), these settings can
be used:
LIBSSH2_CC=clang
LIBSSH2_AR=llvm-ar
LIBSSH2_RANLIB=llvm-ranlib
Also adjust ranlib parameters to be compatible with LLVM/Clang's
ranlib tool.
Closes https://github.com/libssh2/libssh2/pull/214
It breaks SCP download/upload from/to certain server implementations.
The bug does not manifest with OpenSSH, which silently drops the NUL
byte (eventually with any garbage that follows the NUL byte) before
executing it.
Bug: https://bugzilla.redhat.com/1489736
When building with OPENSSL_API_COMPAT=0x10100000L, OpenSSL_add_all_algorithms
and OpenSSL_add_all_ciphers don't exist. The corresponding functionality is
handled automatically with OpenSSL 1.1.
Since they use our own PEM parser which did not support encrypted
PEM files, trying to use such files on these backends failed.
Fix that by augmenting the PEM parser to support encrypted PEM files.
Fixes a segfault using ssh-agent on Windows
This commit fixes a segfault seen dereferencing a null pointer on
Windows when using ssh-agent. The problem ended up being that errors
weren't being communicated all the way through, causing null pointers to
be used when functions should have bailed out sooner.
The `_libssh2_dh_key_pair` function for WinCNG was modified to propagate
errors, and then the two callsites in kex.c of
`diffie_hellman_sha{1,256}` were updated to recognize this error and
bail out.
Fixes#162Closes#163
Not all backends feature the low level API needed to compute a Diffie-Hellman
secret, but some of them directly implement Diffie-Hellman support with opaque
private data. The later approach is now generalized and backends are
responsible for all Diffie Hellman computations.
As a side effect, procedures/macros _libssh2_bn_rand and _libssh2_bn_mod_exp
are no longer needed outside the backends.
Examples can't be linked with libmbedtls but need libmbedcrypto, and
any users of libssh2 which use libtool and libssh2.la would encounter
the same problem.
This changes the mbedtls detection to search for libmbedcrypto, which
is the actual dependency for the backend.
* os400: minimum supported OS version is now V6R1.
Do not log compiler informational messages.
* Implement crypto backend specific Diffie-Hellman computation.
This feature is now needed on os400 because the QC3 library does not
implement bn_mod_exp() natively. Up to now, this function was emulated using
an RSA encryption, but commits ca5222ea819cc5ed797860070b4c6c1aeeb28420 and
7934c9ce2a029c43e3642a492d3b9e494d1542be (CVE-2016-0787) broke the emulation
because QC3 only supports RSA exponents up to 512 bits.
Happily, QC3 supports a native API for Diffie-Hellman computation, with
opaque random value: this commit implements the use of this API and, as a
side effect, enables support of this feature for any other crypto backend that
would use it.
A "generic" Diffie-Hellman computation internal API supports crypto backends
not implementing their own: this generic API uses the same functions as before.
* Fix typos in docs/HACKING.CRYPTO.
The new --with-crypto option replaces the previous backend-specific
--with-{openssl,libgcrypt,mbedtls,wincng} options and fixes some issues.
* libgcrypt or mbedtls would previously be used whenever found, even
if configure was passed --without-libgcrypt or --without-mbedtls.
* If --with-$backend was specified then configure would not fail even
if that library could not be found, and would instead use whichever
crypto library was found first.
The new option defaults to `auto`, which makes configure check for all
supported crypto libraries in turn, choosing the first one found, or
exiting with an error if none can be found.
* Revert "Revert "travis: Test mbedtls too""
This reverts commit c4c60eac5ca756333034b07dd9e0b97741493ed3.
* travis: Build mbedtls from source on Travis
Use TOOLCHAIN_OPTION when calling cmake on mbedtls
* tests: only run DSA tests for non-mbedtls
crypto backends
Most of libssh2 already has conditional support for RSA according to
the LIBSSH2_RSA crypto backend #define, but crypto.h and userauth.c
needed a few small fixes.
The change fixes passing of bogus gcrypt prefix.
Reproducible as:
$ ./configure --with-libgcrypt
$ make V=1
...
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Iyes/include -version-info 1:1:0 -no-undefined -export-symbols-regex '^libssh2_.*' -lgcrypt -lz -Lyes/lib -o libssh2.la -rpath /usr/local/lib channel.lo comp.lo crypt.lo hostkey.lo kex.lo mac.lo misc.lo packet.lo publickey.lo scp.lo session.lo sftp.lo userauth.lo transport.lo version.lo knownhost.lo agent.lo libgcrypt.lo pem.lo keepalive.lo global.lo -lgcrypt
../libtool: line 7475: cd: yes/lib: No such file or directory
libtool: error: cannot determine absolute directory name of 'yes/lib'
These
-Iyes/include
-Lyes/lib
come from libgcrypt code autodetection:
if test -n "$use_libgcrypt" && test "$use_libgcrypt" != "no"; then
LDFLAGS="$LDFLAGS -L$use_libgcrypt/lib"
CFLAGS="$CFLAGS -I$use_libgcrypt/include"
I assume it's a typo to use yes/no flag as a prefix and changed
it to '$with_libgcrypt_prefix'.
Reported-by: Mikhail Pukhlikov <cynede@gentoo.org>
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
The problem is that the original if statement simply returns NULL, but does not set the session last error code. The consequence is that libssh2_sftp_init() also returns NULL and libssh2_session_last_errno(sshSession) == LIBSSH2_ERROR_NONE.
In my test the LIBSSH2_ERROR_EAGAIN is coming from sftp.c row 337:
if(4 != sftp->partial_size_len)
/* we got a short read for the length part */
return LIBSSH2_ERROR_EAGAIN;
with "partial_size_len == 0". Not sure if this is expected.
channel_wait_eof waits for channel->remote.eof, which is set on
receiving a `SSH_MSG_CHANNEL_EOF` message. This message is sent
when a party has no more data to send on a channel.
1> sftp.c
1>libssh2-files\src\sftp.c(3393): warning C4456: declaration of 'retcode' hides previous local declaration
1> libssh2-files\src\sftp.c(3315): note: see declaration of 'retcode'
In order to signal that the requested operation can not succeed
because the receiving window had been exhausted, the error code
LIBSSH2_ERROR_BUFFER_TOO_SMALL has been reused but I have found
that in certain context it may be ambigous.
This patch introduces a new error code,
LIBSSH2_ERROR_CHANNEL_WINDOW_FULL, exclusive to signal that condition.
Until now, in blocking mode, if the remote receiving window is
exhausted this function hangs forever as data is not read and the
remote side just keeps waiting for the window to grow before sending
more data.
This patch, makes this function check for that condition and abort
with an error when it happens.
This function was calling channel_wait_eof to ensure that the EOF
packet has already been received, but that function also checks that
the read data queue is empty before reporting the EOF. That caused
channel_wait_closed to fail with a LIBSSH2_ERROR_INVAL when some data
was queued even after a successful call to libssh2_channel_wait_eof.
This patch changes libssh2_channel_wait_closed to look directly into
channel->remote.eof so that both libssh2_channel_wait_eof and
libssh2_channel_wait_closed bahave consistently.
This partially reverts commit f4f2298ef3635acd031cc2ee0e71026cdcda5864
because it caused the compatibility code to call initialization routines
redundantly, leading to memory leakage with OpenSSL 1.1 and broken curl
test-suite in Fedora:
88 bytes in 1 blocks are definitely lost in loss record 5 of 8
at 0x4C2DB8D: malloc (vg_replace_malloc.c:299)
by 0x72C607D: CRYPTO_zalloc (mem.c:100)
by 0x72A2480: EVP_CIPHER_meth_new (cmeth_lib.c:18)
by 0x4E5A550: make_ctr_evp.isra.0 (openssl.c:407)
by 0x4E5A8E8: _libssh2_init_aes_ctr (openssl.c:471)
by 0x4E5BB5A: libssh2_init (global.c:49)
