|
b43a9e66
|
2020-05-15T17:46:24
|
|
streams: openssl: fix memleak due to us not free'ing certs
When creating a `git_cert` from the OpenSSL X509 certificate of a given
stream, we do not call `X509_free()` on the certificate, leading to a
memory leak as soon as the certificate is requested e.g. by the
certificate check callback.
Fix the issue by properly calling `X509_free()`.
|
|
|
8aa04a37
|
2020-02-19T12:14:16
|
|
Merge pull request #5391 from pks-t/pks/coverity-fixes
Coverity fixes
|
|
|
0119e57d
|
2020-02-11T10:37:32
|
|
streams: openssl: switch approach to silence Valgrind errors
As OpenSSL loves using uninitialized bytes as another source of entropy,
we need to mark them as defined so that Valgrind won't complain about
use of these bytes. Traditionally, we've been using the macro
`VALGRIND_MAKE_MEM_DEFINED` provided by Valgrind, but starting with
OpenSSL 1.1 the code doesn't compile anymore due to `struct SSL` having
become opaque. As such, we also can't set it as defined anymore, as we
have no way of knowing its size.
Let's change gears instead by just swapping out the allocator functions
of OpenSSL with our own ones. The twist is that instead of calling
`malloc`, we just call `calloc` to have the bytes initialized
automatically. Next to soothing Valgrind, this approach has the benefit
of being completely agnostic of the memory sanitizer and is neatly
contained at a single place.
Note that we shouldn't do this for non-Valgrind builds. As we cannot
set up memory functions for a given SSL context, only, we need to swap
them at a global context. Furthermore, as it's possible to call
`OPENSSL_set_mem_functions` once only, we'd prevent users of libgit2 to
set up their own allocators.
|
|
|
b3b92e09
|
2020-02-07T12:56:26
|
|
streams: openssl: ignore return value of `git_mutex_lock`
OpenSSL pre-v1.1 required us to set up a locking function to properly
support multithreading. The locking function signature cannot return any
error codes, and as a result we can't do anything if `git_mutex_lock`
fails. To silence static analysis tools, let's just explicitly ignore
its return value by casting it to `void`.
|
|
cb77423f
|
2019-11-24T16:22:31
|
|
valgrind: add valgrind hints in OpenSSL
Provide usage hints to valgrind. We trust the data coming back from
OpenSSL to have been properly initialized. (And if it has not, it's an
OpenSSL bug, not a libgit2 bug.)
We previously took the `VALGRIND` option to CMake as a hint to disable
mmap. Remove that; it's broken. Now use it to pass on the `VALGRIND`
definition so that sources can provide valgrind hints.
|
|
|
2ad3eb3e
|
2019-11-24T15:59:26
|
|
valgrind: add suppressions for undefined use
valgrind will warn that OpenSSL will use undefined data in connect/read
when talking to certain other TLS stacks. Thankfully, this only seems
to occur when gcc is the compiler, so hopefully valgrind is just
misunderstanding an optimization. Regardless, suppress this warning.
|
|
|
657197e6
|
2019-01-23T15:54:05
|
|
openssl: fix potential size overflow when writing data
Our `openssl_write` function calls `SSL_write` by passing in both `data`
and `len` arguments directly. Thing is, our `len` parameter is of type
`size_t` and theirs is of type `int`. We thus need to clamp our length
to be at most `INT_MAX`.
|
|
|
193e7ce9
|
2019-01-23T15:42:07
|
|
streams: make file-local functions static
The callback functions that implement the `git_stream` structure are
only used inside of their respective implementation files, but they are
not marked as `static`. Fix this.
|
|
|
f1986a23
|
2019-01-21T09:56:23
|
|
streams: don't write more than SSIZE_MAX
Our streams implementation takes a `size_t` that indicates the length of
the data buffer to be written, and returns an `ssize_t` that indicates
the length that _was_ written. Clearly no such implementation can write
more than `SSIZE_MAX` bytes. Ensure that each TLS stream implementation
does not try to write more than `SSIZE_MAX` bytes (or smaller; if the
given implementation takes a smaller size).
|
|
|
f673e232
|
2018-12-27T13:47:34
|
|
git_error: use new names in internal APIs and usage
Move to the `git_error` name in the internal API for error-related
functions.
|
|
|
21142c5a
|
2018-10-29T10:04:48
|
|
http: remove cURL
We previously used cURL to support HTTP proxies. Now that we've added
this support natively, we can remove the curl dependency.
|
|
|
2878ad08
|
2018-10-29T08:59:33
|
|
streams: remove unused tls functions
The implementations of git_openssl_stream_new and
git_mbedtls_stream_new have callers protected by #ifdefs and
are never called unless compiled in. There's no need for a
dummy implementation. Remove them.
|
|
|
43b592ac
|
2018-10-25T08:49:01
|
|
tls: introduce a wrap function
Introduce `git_tls_stream_wrap` which will take an existing `stream`
with an already connected socket and begin speaking TLS on top of it.
This is useful if you've built a connection to a proxy server and you
wish to begin CONNECT over it to tunnel a TLS connection.
Also update the pluggable TLS stream layer so that it can accept a
registration structure that provides an `init` and `wrap` function,
instead of a single initialization function.
|
|
03994912
|
2018-08-29T01:57:24
|
|
openssl: only say we're connected if the connection succeeded
ssl_close uses this boolean to know if SSL_shutdown should be called.
It turns out OpenSSL auto-shutdowns on failure, so if the call to
SSL_connect fails, it will complain about "shutdown while in init",
trampling the original error.
|
|
|
caee0a66
|
2018-08-29T01:57:22
|
|
openssl: set the error class to GITERR_SSL
|
|
|
75395c87
|
2018-06-29T13:35:14
|
|
streams: report OpenSSL errors if global init fails
In case when the global initialization of the OpenSSL stream fails, the
user is left without any hint as to what went wrong as we do not provide
any error message at all. This commit refactors the init function to
have a common error path, which now also sets an error message including
the error string provided by OpenSSL.
|
|
05d89e72
|
2018-06-25T17:30:04
|
|
streams: openssl: Handle error in SSL_CTX_new
SIGSEGV otherwise...
|
|
b1cab70b
|
2018-05-30T02:15:09
|
|
streams: openssl: add missing check on OPENSSL_LEGACY_API
The `CRYPTO_THREADID` type is no longer available in OpenSSL ≥ 1.1.0 with deprecated features disabled, and causes build failures. Since the `threadid_cb()` function is only ever called by `git_openssl_set_locking()` when `defined(OPENSSL_LEGACY_API)`, only define it then.
|
|
|
ba5e39ac
|
2018-05-04T15:25:11
|
|
streams: openssl: fix bogus warning on unused parameter
Our provided callback function `threadid_cb(CRYPTO_THREADID
*threadid)` sets up a unique thread ID by asking pthread for the
current thread ID. Since openssl version 1.1,
`CRYPTO_THREADID_set_numeric` is simply a no-op macro, leaving
the `threadid` argument unused after the preprocessor has
processed the macro. GCC does not account for that situation and
will thus complain about `threadid` being unused.
Silence this warning by using `GIT_UNUSED(threadid)`.
|
|
|
173a0375
|
2018-02-08T23:50:14
|
|
openssl: remove leftover #ifdef
This is the "OpenSSL available" global init function after all
|
|
|
dd9de88a
|
2018-04-03T11:57:45
|
|
streams: openssl: provide `OPENSSL_init_ssl` for legacy API
In order to further avoid using ifdef's in our code flow, provide the
function `OPENSSL_init_ssl` in case we are using the legacy OpenSSL API.
|
|
|
ede63b99
|
2018-04-03T11:45:00
|
|
streams: openssl: unify version checks into single define
By now, we have several locations where we are checking the version of
OpenSSL to determine whether we can use the new "modern" API or need to
use the pre-1.1 legacy API. As we have multiple implementations of
OpenSSL with the rather recent libressl implementation, these checks
need to honor versions of both implementations, which is rather tedious.
Instead, we can just check once for the correct versions and define
`OPENSSL_LEGACY_API` in case we cannot use the modern API.
|
|
|
2505cbfc
|
2018-04-03T11:40:39
|
|
streams: openssl: move OpenSSL compat layer into implementation
OpenSSL version 1.1 has broken its API in quite a few ways. To avoid
having to use ifdef's everywhere, we have implemented the BIO functions
added in version 1.1 ourselves in case we are using the legacy API. We
were implementing them in the header file, though, which doesn't make a
lot of sense, since these functions are only ever being used the the
openssl stream implementation.
Move these functions to the implementation file and mark them static.
|
|
7490d449
|
2018-04-02T20:00:07
|
|
Fix build with LibreSSL 2.7
LibreSSL 2.7 adds OpenSSL 1.1 API
Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>
|
|
|
84f03b3a
|
2018-02-16T10:48:55
|
|
streams: openssl: fix use of uninitialized variable
When verifying the server certificate, we do try to make sure that the
hostname actually matches the certificate alternative names. In cases
where the host is either an IPv4 or IPv6 address, we have to compare the
binary representations of the hostname with the declared IP address of
the certificate. We only do that comparison in case we were successfully
able to parse the hostname as an IP, which would always result in the
memory region being initialized. Still, GCC 6.4.0 was complaining about
usage of non-initialized memory.
Fix the issue by simply asserting that `addr` needs to be initialized.
This shuts up the GCC warning.
|
|
|
a223bae5
|
2018-01-03T14:57:25
|
|
Merge pull request #4437 from pks-t/pks/openssl-hash-errors
hash: openssl: check return values of SHA1_* functions
|
|
|
ba56f781
|
2018-01-03T12:54:42
|
|
streams: openssl: fix thread-safety for OpenSSL error messages
The function `ERR_error_string` can be invoked without providing a
buffer, in which case OpenSSL will simply return a string printed into a
static buffer. Obviously and as documented in ERR_error_string(3), this
is not thread-safe at all. As libgit2 is a library, though, it is easily
possible that other threads may be using OpenSSL at the same time, which
might lead to clobbered error strings.
Fix the issue by instead using a stack-allocated buffer. According to
the documentation, the caller has to provide a buffer of at least 256
bytes of size. While we do so, make sure that the buffer will never get
overflown by switching to `ERR_error_string_n` to specify the buffer's
size.
|
|
|
8be2a790
|
2017-12-05T23:21:05
|
|
openssl: free the peer certificate
Per SSL_get_peer_certificate docs:
```
The reference count of the X509 object is incremented by one, so that it will not be destroyed when the session containing the peer certificate is freed. The X509 object must be explicitly freed using X509_free().
```
|
|
|
2518eb81
|
2017-11-24T14:04:10
|
|
openssl: merge all the exit paths of verify_server_cert
This makes it easier to cleanup allocated resources on exit.
|
|
|
2d2e70f8
|
2017-11-30T18:10:28
|
|
openssl: fix thread-safety on non-glibc POSIX systems
While the OpenSSL library provides all means to work safely in a
multi-threaded application, we fail to do so correctly. Quoting from
crypto_lock(3):
OpenSSL can safely be used in multi-threaded applications provided
that at least two callback functions are set, locking_function and
threadid_func.
We do in fact provide the means to set up the locking function via
`git_openssl_set_locking()`, where we initialize a set of locks by using
the POSIX threads API and set the correct callback function to lock and
unlock them.
But what we do not do is setting the `threadid_func` callback. This
function is being used to correctly locate thread-local data of the
OpenSSL library and should thus return per-thread identifiers. Digging
deeper into OpenSSL's documentation, the library does provide a fallback
in case that locking function is not provided by the user. On Windows
and BeOS we should be safe, as it simply "uses the system's default
thread identifying API". On other platforms though OpenSSL will fall
back to using the address of `errno`, assuming it is thread-local.
While this assumption holds true for glibc-based systems, POSIX in fact
does not specify whether it is thread-local or not. Quoting from
errno(3p):
It is unspecified whether errno is a macro or an identifier declared
with external linkage.
And in fact, with musl there is at least one libc implementation which
simply declares `errno` as a simple `int` without being thread-local. On
those systems, the fallback threadid function of OpenSSL will not be
thread-safe.
Fix this by setting up our own callback for this setting. As users of
libgit2 may want to set it themselves, we obviously cannot always set
that function on initialization. But as we already set up primitives for
threading in `git_openssl_set_locking()`, this function becomes the
obvious choice where to implement the additional setup.
|
|
|
22317057
|
2017-03-21T00:36:32
|
|
https: Prevent OpenSSL from namespace-leaking
|
|
|
e9369856
|
2017-03-21T00:25:15
|
|
stream: Gather streams to src/streams
|