... if the pointer subtraction of sp1 - pubkey - 1 resulted in a
negative or larger value than pubkey_len, memchr would fail.
Reported by Coverity CID 89846.
... host cannot be NULL in line 525, because it is always
valid (e.g. at least set to "0.0.0.0") after lines 430 and 431.
Reported by Coverity CID 89807.
Fixes VS2012 code analysis warning C6386:
buffer overrun: accessing 'pbOutput', the writable size is
'cbOutput' bytes, but '3' bytes may be written: libssh2 wincng.c 610
Fixes VS2012 code analysis warning C6387: 'p+4' may be '0':
this does not adhere to the specification for the function
'memcpy': libssh2 agent.c 330
Fixes VS2012 code analysis warning C6387: 'p' may be '0':
this does not adhere to the specification for the function
'UnmapViewOfFile': libssh2 agent.c 333
test/GNUmakefile: added architecture autodetection; added switches to
CFLAGS and RCFLAGS to make sure that the right architecture is used.
Added support to build with WinCNG.
Added architecture autodetection; added switches to CFLAGS and
RCFLAGS to make sure that the right architecture is used.
Added support to build with WinCNG.
Initially reported by Bob Kast as "for MS VS builds, specify the
libraries that are required so they don't need to go into all
project files that may use this library". Thanks a lot.
If you are building a DLL, then you need to explicitly export each
entry point. When building a static library, you should not.
libssh2 was exporting the entry points whether it was building a DLL or a
static library. To elaborate further, if libssh2 was used as a static
library, which was being linked into a DLL, the libssh2 API would be
exported from that separate DLL.
This avoids line-wrapping in between parameters and makes the
error message look like the following:
configure: error: No crypto library found!
Try --with-libssl-prefix=PATH
or --with-libgcrypt-prefix=PATH
or --with-wincng on Windows
Initially reported by Bob Kast as "Wincng - define function
prototypes for wincng routines". Thanks a lot.
Also replaced structure definitions with type definitions.
Inspired by Bob Kast's reports, this commit enables the compilation
of libssh2 with WinCNG using the generated Visual Studio project files.
This commit adds WinCNG support to parts of the existing Win32 build
infrastructure, until new build systems, like pre-defined VS project
files or CMake files may be added.
This commit and b20bfeb3e5 raise one
question: How to handle build systems, like VS project files, that
need to include all source files regardless of the desired target,
including all supported crypto backends? For now the mentioned commit
added a check for LIBSSH2_OPENSSL to openssl.c and with this commit
the supported crypto backends are hardcoded within Makefile.am.
Removed header file combination that is not supported on a real
Windows platform and can only be compiled using MinGW. Replaced
custom NTSTATUS return code checks with BCRYPT_SUCCESS macro.
../src/knownhost.c: In function 'libssh2_knownhost_readline':
../src/knownhost.c:651:16: warning: 'key_type_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
rc = knownhost_add(hosts, hostbuf, NULL,
^
../src/knownhost.c:745:12: note: 'key_type_len' was declared here
size_t key_type_len;
^
Commit d512b25f69 introduced a crypto
library abstraction in the autotools build system, to allow us to more
easily support new crypto libraries. In that process it was found that
all other build system which we support are hard-coded to build with
OpenSSL. Commit f5c1a0d98b fixes automake
introduced into non-autotools build systems but still overlooked the
CPP macro saying that we are using OpenSSL.
Thanks to Marc Hörsken for identifying this issue and proposing a fix
for win32/{GNUmakefile,config.mk}. This commit uses a slightly different
approach but the end result is the same.
Commit 85c6627c changed the behaviour of `libssh2_knownhost_writeline` so that it stopped returning the number of bytes needed when the given buffer was too small. Also, the function changed such that is might write to part of the buffer before realising it is too small.
This commit restores the original behaviour, whilst keeping the unknown-key-type functionality that 85c6627c. Instead of writing to the buffer piecemeal, the length of the various parts is calculated up front and the buffer written only if there is enough space. The calculated necessary size is output in `outlen` regardless of whether the buffer was written to.
The main use-case for the original behaviour that this commit restores is to allow passing in a NULL buffer to get the actual buffer size needed, before calling the function again with the buffer allocated to the exact size required.
The first might occur if _libssh2_packet_add returns an error, as
fullpacket_state wasn't reset to idle so if it were possible for
fullpacket to be called again, it would return to the same state
handler and re-use the freed p->packet buffer.
The second could occur if decrypt returned an error, as it freed the
packet buffer but did not clear total_num, meaning that freed buffer
could be written into again later.
In one case, the error code from `_libssh2_transport_read` was being returned from `_libssh2_channel_write` without setting it as the last error by calling `_libssh2_error`. This commit fixes that.
Found when using a session whose socket had been inadvertently destroyed. The calling code got confused because via `libssh2_session_last_error` it appeared no error had occurred, despite one being returned from the previous function.
When using the OpenSSL libraries in FIPS mode, the function call
EVP_DigestInit() is actually #defined to FIPS_digestinit().
Unfortunately wheres EVP_DigestInit() initialises the context and then
calls EVP_DigestInit_ex(), this function assumes that the context has
been pre-initialised and crashes when it isn't.
Bug: https://trac.libssh2.org/ticket/279Fixes#279
Commit d512b25f69 added automake
conditionals to Makefile.inc but since Makefile.inc is included
from Makefile for all other build systems that does not work.
This commit instead adds Makefile.OpenSSL.inc and Makefile.libgcrypt.inc
and moves the automake conditional to its proper place, src/Makefile.am.
The automake conditional includes the correct Makefile.$name.inc per
the crypto library selection/detection done by configure.
All non-autotools build system files in libssh2 are hardcoded to use
OpenSSL and do not get a conditional but at least there is some reuse
because they can all include the new Makefile.OpenSSL.inc.
The default channel window size used until now was 256KB. This value is
too small and results on a bottleneck on real-life networks where
round-trip delays can easily reach 300ms.
The issue was not visible because the configured channel window size
was being ignored and a hard-coded value of ~22MB being used instead,
but that was fixed on a previous commit.
This patch just changes the default window size
(LIBSSH2_CHANNEL_WINDOW_DEFAULT) to 2MB. It is the same value used by
OpenSSH and in our opinion represents a good compromise between memory
used and transfer speed.
Performance tests were run to determine the optimum value. The details
and related discussion are available from the following thread on the
libssh2 mailing-list:
http://www.libssh2.org/mail/libssh2-devel-archive-2013-10/0018.shtmlhttp://article.gmane.org/gmane.network.ssh.libssh2.devel/6543
An excerpt follows:
"I have been running some transfer test and measuring their speed.
My setup was composed of a quad-core Linux machine running Ubuntu 13.10
x86_64 with a LXC container inside. The data transfers were performed
from the container to the host (never crossing through a physical
network device).
Network delays were simulated using the tc tool. And ping was used to
verify that they worked as intended during the tests.
The operation performed was the equivalent to the following ssh command:
$ ssh container "dd bs=16K count=8K if=/dev/zero" >/dev/null
Though, establishment and closing of the SSH connection was excluded
from the timings.
I run the tests several times transferring files of sizes up to 128MB
and the results were consistent between runs.
The results corresponding to the 128MB transfer are available here:
https://docs.google.com/spreadsheet/ccc?key=0Ao1yRmX6PQQzdG5wSFlrZl9HRWNET3ZyN0hnaGo5ZFE&usp=sharing
It clearly shows that 256KB is too small as the default window size.
Moving to a 512MB generates a great improvement and after the 1MB mark
the returns rapidly diminish. Other factors (TCP window size, probably)
become more limiting than the channel window size
For comparison I also performed the same transfers using OpenSSH. Its
speed is usually on par with that of libssh2 using a window size of 1MB
(even if it uses a 2MB window, maybe it is less aggressive sending the
window adjust msgs)."
Signed-off-by: Salvador Fandino <sfandino@yahoo.com>
_libssh2_channel_read was using an arbitrary hard-coded limit to trigger
the window adjusting code. The adjustment used was also hard-coded and
arbitrary, 15MB actually, which would limit the usability of libssh2 on
systems with little RAM.
This patch, uses the window_size parameter passed to
libssh2_channel_open_ex (stored as remote.window_size_initial) plus the
buflen as the base for the trigger and the adjustment calculation.
The memory usage when using the default window size is reduced from 22MB
to 256KB per channel (actually, if compression is used, these numbers
should be incremented by ~50% to account for the errors between the
decompressed packet sizes and the predicted sizes).
My tests indicate that this change does not impact the performance of
transfers across localhost or a LAN, being it on par with that of
OpenSSH. On the other hand, it will probably slow down transfers on
networks with high bandwidth*delay when the default window size
(LIBSSH2_CHANNEL_WINDOW_DEFAULT=256KB) is used.
Signed-off-by: Salvador Fandino <sfandino@yahoo.com>
Store but don't use keys of unsupported types on the known_hosts file.
Currently, when libssh2 parses a known_host file containing keys of some
type it doesn't natively support, it stops reading the file and returns
an error.
That means, that the known_host file can not be safely shared with other
software supporting other key types (i.e. OpenSSH).
This patch adds support for handling keys of unknown type. It can read
and write them, even if they are never going to be matched.
At the source level the patch does the following things:
- add a new unknown key type LIBSSH2_KNOWNHOST_KEY_UNKNOWN
- add a new slot (key_type_name) on the known_host struct that is
used to store the key type in ascii form when it is not supported
- parse correctly known_hosts entries with unknown key types and
populate the key_type_name slot
- print correctly known_hosts entries of unknown type
- when checking a host key ignore keys that do not match the key
Fixes#276
Deflate may return Z_OK even when not all data has been compressed
if the output buffer becomes full.
In practice this is very unlikely to happen because the output buffer
size is always some KBs larger than the size of the data passed for
compression from the upper layers and I think that zlib never expands
the data so much, even on the worst cases.
Anyway, this patch plays on the safe side checking that the output
buffer is not exhausted.
Signed-off-by: Salvador <sfandino@yahoo.com>
The old algorithm was O(N^2), causing lots and lots of reallocations
when highly compressed data was transferred.
This patch implements a simpler one that just doubles the buffer size
everytime it is exhausted. It results in O(N) complexity.
Also a smaller inflate ratio is used to calculate the initial size (x4).
Signed-off-by: Salvador <sfandino@yahoo.com>
Data may remain in zlib internal buffers when inflate() returns Z_OK
and avail_out == 0. In that case, inflate has to be called again.
Also, once all the data has been inflated, it returns Z_BUF_ERROR to
signal that the input buffer has been exhausted.
Until now, the way to detect that a packet payload had been completely
decompressed was to check that no data remained on the input buffer
but that didn't account for the case where data remained on the internal
zlib buffers.
That resulted in packets not being completely decompressed and the
missing data reappearing on the next packet, though the bug was masked
by the buffer allocation algorithm most of the time and only manifested
when transferring highly compressible data.
This patch fixes the zlib usage.
Signed-off-by: Salvador <sfandino@yahoo.com>
After filling the read buffer with data from the read queue, when the
window size was too small, "libssh2_channel_receive_window_adjust" was
called to increase it. In non-blocking mode that function could return
EAGAIN and, in that case, the EAGAIN was propagated upwards and the data
already read on the buffer lost.
The function was also moving between the two read states
"libssh2_NB_state_idle" and "libssh2_NB_state_created" both of which
behave in the same way (excepting a debug statment).
This commit modifies "_libssh2_channel_read" so that the
"libssh2_channel_receive_window_adjust" call is performed first (when
required) and if everything goes well, then it reads the data from the
queued packets into the read buffer.
It also removes the useless "libssh2_NB_state_created" read state.
Some rotted comments have also been updated.
Signed-off-by: Salvador <sfandino@yahoo.com>
Until now, the window size (channel->remote.window_size) was being
updated just after receiving the packet from the transport layer.
That behaviour is wrong because the channel queue may grow uncontrolled
when data arrives from the network faster that the upper layer consumes
it.
This patch adds a new counter, read_avail, which keeps a count of the
bytes available from the packet queue for reading. Also, now the window
size is adjusted when the data is actually read by an upper layer.
That way, if the upper layer stops reading data, the window will
eventually fill and the remote host will stop sending data. When the
upper layers reads enough data, a window adjust packet is delivered and
the transfer resumes.
The read_avail counter is used to detect the situation when the remote
server tries to send data surpassing the window size. In that case, the
extra data is discarded.
Signed-off-by: Salvador <sfandino@yahoo.com>
libssh2 used to explicitly check for libgcrypt and default to OpenSSL.
Now all possible crypto libraries are checked for explicitly, making
the addition of further crypto libraries both simpler and cleaner.
Fixes issue arising when server does not support statfvs and or fstatvfs
extensions. sftp_statvfs() and sftp_fstatvfs() after this patch will
handle the case when SSH_FXP_STATUS is returned from server.
This partially reverts commit 03ca902075
in order to fix extreme slowdown when uploading to localhost via SFTP.
I was able to repeat the issue on RHEL-7 on localhost only. It did not
occur when uploading via network and it did not occur on a RHEL-6 box
with the same version of libssh2.
The problem was that sftp_read() used a read-ahead logic to figure out
the window_size, but sftp_packet_read() called indirectly from
sftp_write() did not use any read-ahead logic.
When there's no window to "write to", there's no point in waiting for
the socket to become writable since it most likely just will continue to
be.
Patch-by: ncm
Fixes#258
In _libssh2_packet_add, called by _libssh2_packet_read, a call to
_libssh2_packet_send that is supposed to send a one-byte message
SSH_MSG_REQUEST_FAILURE would send an uninitialized byte upon re-entry
if its call to _send returns _EAGAIN.
Fixes#259
The new libssh2_sftp_fsync API causes data and metadata in the
currently open file to be committed to disk at the server.
This is an OpenSSH extension to the SFTP protocol. See:
https://bugzilla.mindrot.org/show_bug.cgi?id=1798
... in macro parameters to avoid compiler warnings about lost precision.
Several macros in libssh2.h call strlen and pass the result directly to
unsigned int parameters of other functions, which warns about precision
loss because strlen returns size_t which is unsigned long on at least
some platforms (such as OS X). The fix is to simply typecast the
strlen() result to unsigned int.
libssh2_knownhost_readfile() silently ignored problems when reading keys
in unsupported formats from the known hosts file. When the file is
written again from the internal structures of libssh2 it gets truntcated
to the point where the first unknown key was located.
* src/knownhost.c:libssh2_knownhost_readfile() - return error if key
parsing fails
Add a "use_in_auth" flag to the LIBSSH2_COMP_METHOD struct and a
separate "zlib@openssh.com" method, along with checking session->state
for LIBSSH2_STATE_AUTHENTICATED. Appears to work on the OpenSSH servers
I've tried against, and it should work as before with normal zlib
compression.
If libssh2_session_free is called without the channel being freed
previously by libssh2_channel_free a memory leak could occur.
A mismatch of states variables in session_free() prevent the call to
libssh2_channel_free function. session->state member is used instead of
session->free_state.
It causes a leak of around 600 bytes on every connection on my systems
(Linux, x64 and PPC).
(Debugging done under contract for Accedian Networks)
Fixes#246
When using libssh2 to perform an SFTP file transfer from the "JSCAPE MFT
Server" (http://www.jscape.com) the transfer failed. The default JSCAPE
configuration is to enforce zlib compression on SSH2 sessions so the
session was compressed. The relevant part of the debug trace contained:
[libssh2] 1.052750 Transport: unhandled zlib error -5
[libssh2] 1.052750 Failure Event: -29 - decompression failure
The trace comes from comp_method_zlib_decomp() in comp.c. The "unhandled
zlib error -5" is the status returned from the zlib function
inflate(). The -5 status corresponds to "Z_BUF_ERROR".
The inflate() function takes a pointer to a z_stream structure and
"inflates" (decompresses) as much as it can. The relevant fields of the
z_stream structure are:
next_in - pointer to the input buffer containing compressed data
avail_in - the number of bytes available at next_in
next_out - pointer to the output buffer to be filled with uncompressed
data
avail_out - how much space available at next_out
To decompress data you set up a z_stream struct with the relevant fields
filled in and pass it to inflate(). On return the fields will have been
updated so next_in and avail_in show how much compressed data is yet to
be processed and next_out and avail_out show how much space is left in
the output buffer.
If the supplied output buffer is too small then on return there will be
compressed data yet to be processed (avail_in != 0) and inflate() will
return Z_OK. In this case the output buffer must be grown, avail_out
updated and inflate() called again.
If the supplied output buffer was big enough then on return the
compressed data will have been exhausted (avail_in == 0) and inflate()
will return Z_OK, so the data has all been uncompressed.
There is a corner case where inflate() makes no progress. That is, there
may be unprocessed compressed data and space available in the output
buffer and yet the function does nothing. In this case inflate() will
return Z_BUF_ERROR. From the zlib documentation and the source code it
is not clear under what circumstances this happens. It could be that it
needs to write multiple bytes (all in one go) from its internal state to
the output buffer before processing the next chunk of input but but
can't because there is not enough space (though my guesses as to the
cause are not really relevant). Recovery from Z_BUF_ERROR is pretty
simple - just grow the output buffer, update avail_out and call
inflate() again.
The comp_method_zlib_decomp() function does not handle the case when
inflate() returns Z_BUF_ERROR. It treats it as a non-recoverable error
and basically aborts the session.
Fixes#240
Changed to use Windows commandline tools instead of
GNU tools when compiling on Windows. Fixed dist and
dev targets. Enabled nlmconv error for unresolved
symbols.
Usually a format macro should hold the whole format, otherwise
it should be named a prefix. Also fixed usage of this macro in
scp.c for a signed var where it was used as prefix for unsigned.
Rationale: Everything else in this file states a fact about the win32
platform that is unconditional for that platform. There is nothing
unconditional about the presence of zlib. It is neither included with
Windows nor with the platform SDK. Therefore, this is not an appropriate
place to assert its presence. Especially as, once asserted, it cannot be
overridden using a compiler flag.
In contrast, if it is omitted, then it can easily be reasserted by adding
a compiler flag defining LIBSSH2_HAVE_ZLIB.
sftp_packet_add takes ownership of the packet passed to it and (now that we
handle zombies) might free the packet. sftp_packet_read uses the packet type
byte as its return code but by this point sftp_packet_add might have freed
it. This change fixes the problem by caching the packet type before calling
sftp_packet_add.
I don't understand why sftp_packet_read uses the packet type as its return
code. A future change might get rid of this entirely.
As this function is called when the SFTP session is closed, it needs to
also kill all zombies left in the SFTP session to avoid leaking memory
just in case some zombie would still be in there.
When flushing the packetlist, we must only add the request as a zombie
if no response has already been received. Otherwise we could wrongly
make it a zombie even though the response was already received and then
we'd get a zombie stuck there "forever"...
Since the sftp_packetlist_flush() function will move all the existing
FXP_READ requests in this handle to the zombie list we must first remove
this just received packet as it is clearly not a zombie.
Exactly as the comment in the code said, checking the return code from
sftp_packet_read() with <= was wrong and it should be < 0. With the new
filtering on incoming packets that are "zombies" we can now see this
getting zero returned.
In order to be fast, sftp_read sends many read requests at once. With a small
file, this can mean that when EOF is received back, many of these requests are
still outstanding. Responses arriving after we close the file and abandon the
file handle are queued in the SFTP packet queue and never collected. This
causes transfer speed to drop as a progressively longer queue must be searched
for every packet.
This change introduces a zombie request-ID list in the SFTP session that is
used to recognise these outstanding requests and prevent them being added to
the queue.
libcrypto on win32 now depends on gdi32.dll, so move the OpenSSL LDLIBS
block to before the compiler definitions, so that libcrypto gets added
first, and then add -lgdi32 into the following common LDLIBS for gcc.
Examples are built by default. Any of the following options on the
configure command line will skip building them:
--disable-examples-build
--enable-examples-build=no
--enable-examples-build=false
If the filename parameter for file_read_publickey() was the name of a
directory instead of a file then libssh2 would spin trying to fgetc()
from the FILE * for the opened directory when trying to determine the
length of the encoded public key, since fgetc() can't report errors.
Use fread() instead to correctly detect this error condition along
with many others.
This fixes the problem reported in
http://www.libssh2.org/mail/libssh2-devel-archive-2012-04/0021.shtml
Reported-by: Oleksiy Zagorskyi <zalex_ua@i.ua>
When calling _libssh2_channel_receive_window_adjust() internally, we now
always use the 'force' option to prevent libssh2 to avoid sending the
update if the update isn't big enough.
It isn't fully analyzed but we have seen corner cases which made a
necessary window update not get send due to this and then the other side
doesn't send data our side then sits waiting for forever.
if there's not enough room to receive the data that's being requested,
the window adjustment needs to be sent to the remote and thus the force
option has to be used. _libssh2_channel_receive_window_adjust() would
otherwise "queue" small window adjustments for a later packet but that
is really terribly for the small buffer read that for example is the
final little piece of a very large file as then there is no logical next
packet!
Reported by: Armen Babakhanian
Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2012-03/0130.shtml
_libssh2_channel_write() first reads outstanding packets before writing
new data. If it reads a key exchange request, it will immediately start
key re-exchange, which will require sending a response. If the output
socket is full, this will result in a return from
_libssh2_transport_read() of LIBSSH2_ERROR_EAGAIN. In order not to block
a write because there is no data to read, this error is explicitly
ignored and the code continues marshalling a packet for sending. When it
is sent, the remote end immediately drops the connection because it was
expecting a continuation of the key exchange, but got a data packet.
This change adds the same check for key exchange to
_libssh2_transport_send() that is in _libssh2_transport_read(). This
ensures that key exchange is completed before any data packet is sent.
When draining data off the socket with _libssh2_transport_read() (which
in turn has to be done so that we can be sure to have read any possible
window-increasing packets), this code previously ignored errors which
could lead to nasty loops. Now all error codes except EAGAIN will cause
the error to be returned at once.
Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2012-03/0068.shtml
Reported by: Matthew Booth
sizeof(buf) expands to 8 or 4 (since its a pointer). This variable may
have been static in the past, leading to this error.
Signed-off-by: Steven Dake <sdake@redhat.com>
In the x11 example, sizeof(buf) = 8UL (on x86_64), when this should
probably represent the buffer size available. I am not sure how to
test that this change is actually correct, however.
Signed-off-by: Steven Dake <sdake@redhat.com>
Lots of places in the code translated the original error into the more
generic LIBSSH2_ERROR_SOCKET_TIMEOUT but this turns out to distort the
original error reason a lot and makes tracking down the real origin of a
problem really hard. This change makes the original error code be
preserved to a larger extent when return up to the parent function.
Commit 03ca902075 tried to simplify the window sizing logic but broke
SFTP readdir as there was no window sizing code left there so large
directory listings no longer worked.
This change introduces window sizing logic to the sftp_packet_read()
function so that it now tells the remote about the local size having a
window size that suffice when it is about to ask for directory data.
Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2012-03/0069.shtml
Reported by: Eric
The call of libssh2_init returns a return code, but nothing could be done
within the _libssh2_init_if_needed execution path.
Signed-off-by: Steven Dake <sdake@redhat.com>
Although the function checks the length, if the code was in error, there
could potentially be a buffer overrun with the use of sprintf. Instead replace
with snprintf.
Signed-off-by: Steven Dake <sdake@redhat.com>
INVALID_SOCKET is a special value in Windows representing a
non-valid socket identifier. We were #defining this to -1 on
non-Windows platforms, causing unneccessary namespace pollution.
Let's have our own identifier instead.
Thanks to Matt Lawson for pointing this out.
OpenSolaris has no cfmakeraw() so to make the example more portable
we simply do the equivalent operations on struct termios ourselves.
Thanks to Tom Weber for reporting this problem, and finding a solution.
Whenever we have acked data and is about to call a function that *MAY*
return EAGAIN we must return the number now and wait to get called
again. Our API only allows data *or* EAGAIN and we must never try to get
both.
Removed the total_read variable that originally must have tracked how
much data had been written to the buffer. With non-blocking reads, we
must return straight away once we have read data into the buffer so this
variable served not purpose.
I think it was still hanging around in case the initial processing of
'leftover' data meant we wrote to the buffer but this case, like the
others, must return immediately. Now that it does, the last remaining
need for the variable is gone.
Whenever we have data and is about to call a function that *MAY* return
EAGAIN we must return the data now and wait to get called again. Our API
only allows data *or* EAGAIN and we must never try to get both.
If the function that extracts/computes the public key from a private key
fails the errors it reports were masked by the function calling it. This
patch modifies the key extraction function to return errors using
_libssh_error() function. The error messages are tweaked to contain
reference to the failed operaton in addition to the reason.
* AUTHORS: - add my name
* libgcrypt.c: _libssh2_pub_priv_keyfile(): - return a more verbose
error using
_libssh2_error() func.
* openssl.c: - modify call graph of _libssh2_pub_priv_keyfile() to use
_libssh2_error for error reporting();
* userauth.c: - tweak functions calling _libssh2_pub_priv_keyfile() not
to shadow error messages
Some SFTP servers send SFTP packets larger than 40000. Since the limit
is only present to avoid insane sizes anyway, we can easily bump it.
The define was formerly in the public header libssh2_sftp.h but served
no external purpose and was moved into the source dir.
Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2011-11/0004.shtml
Reported by: Michael Harris
Documentation for libssh2_knownhost_checkp() and related functions
states that the last argument is filled with data if non-NULL.
"knownhost if set to non-NULL, it must be a pointer to a 'struct
libssh2_knownhost' pointer that gets filled in to point to info about a
known host that matches or partially matches."
In this function ext is dereferenced even if set to NULL, causing
segfault in applications not needing the extra data.
In function knownhost_add, memory is alocated for a new entry. If normal
alocation is used, memory is not initialized to 0 right after, but a
check is done to verify if correct key type is passed. This test is done
BEFORE setting the memory to null, and on the error path function
free_host() is called, that tries to dereference unititialized memory,
resulting into a glibc abort().
* knownhost.c - knownhost_add(): - move typemask check before alloc
When cross compiling to Windows, libssh2.h include Windows header files
with upper case filenames : BaseTsd.h and WinSock2.h.
These files have lowercase names with mingw-w64 (iirc, it's the same with
mingw). And as on Windows, being lowercase or uppercase does not matter.
Make sure we don't clear or reset static structs after first init so
that they work fine even when used from multiple threads. Init the
structs in the global init.
Help and assistance by: John Engstrom
Fixes#229 (again)
make_ctr_evp() is changed to take a struct pointer, and then each
_libssh2_EVP_aes_[keylen]_ctr function is made to pass in their own
static struct
Reported by: John Engstrom
Fixes#229
Set read_state back to idle before trying to send anything so that if
the state somehow is wrongly set.
Also, avoid such a case of confusion by resetting the read_state when an
sftp handle is closed.
Removed the automatic window_size adjustments from
_libssh2_channel_read() and instead all channel readers must now make
sure to enlarge the window sizes properly themselves.
libssh2_channel_read_ex() - the public function, now grows the window
size according to the requested buffer size. Applications can still opt
to grow the window more on demand. Larger windows tend to give higher
performance.
sftp_read() now uses the read-ahead logic to figure out a window_size.
A returned READ packet that is short will now only reduce the
offset.
This is a temporary fix as it is slightly better than the previous
approach but still not very good.
When receiving more data than what the window size allows on a
particular channel, make sure that the window size is adjusted in that
case too. Previously it would only adjust the window in the non-error
case.
When seeking to a new position, flush the packetlist and buffered data
to prevent already received or pending data to wrongly get used when
sftp-reading from the new offset within the file.
In the case where a read packet has been received from the server, but
the entire contents couldn't be copied to the user-buffer, the data is
instead buffered and copied to the user's buffer in the next invocation
of sftp_read(). When that "extra" copy is made, the 'offset' pointer was
not advanced accordingly.
The biggest impact of this flaw was that the 'already' variable at the
top of the function that figures out how much data "ahead" that has
already been asked for would slowly go more and more out of sync, which
could lead to the file not being read all the way to the end.
This problem was most noticable in cases where the application would
only try to read the exact file size amount, like curl does. In the
examples libssh2 provides the sftp read function is most often called
with a fixed size large buffer and then the bug would not appear as
easily.
This bug was introduced in the SFTP rewrite in 1.2.8.
Bug: http://curl.haxx.se/mail/lib-2011-08/0305.htmlhttp://www.libssh2.org/mail/libssh2-devel-archive-2011-08/0085.shtml
.THlibssh2_session_init_ex3"1 Jun 2007""libssh2 0.15""libssh2 manual"
.SHNAME
libssh2_session_init_ex - initializes an SSH session object
@@ -41,4 +39,4 @@ starting up an SSH session with a remote server.
Pointer to a newly allocated LIBSSH2_SESSION instance, or NULL on errors.
.SHSEEALSO
.BRlibssh2_session_free(3)
.BRlibssh2_session_startup(3)
.BRlibssh2_session_handshake(3)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
