Stack Overflow has a number of questions related to mutual authentication,
the client and its certificate. Those visiting the man pages for functions
like SSL_CTX_use_certificate and SSL_CTX_load_verify_locations don't
receive the benefit of a cross reference to SSL_CTX_set_client_CA_list.
Reviewed-by: Richard Levitte <levitte@openssl.org>
- srtp_profiles variable is defined when building with SRTP, keeping
the variable usage also under ifndef OPENSSL_NO_SRTP
- alpn help option was kept under ifndef OPENSSL_NO_SRTP
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The INCLUDE statement can handle setting extra include directories for
individual object files, let's use it.
Reviewed-by: Andy Polyakov <appro@openssl.org>
I read the PROBLEMS, and they're outdated; nothing I'd put in the
online FAQ, for example. Test-builds work without using these files.
Had to remove the rehash.time stuff from Makefile.in
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reformat EC_POINT_new.pod and add parentheses to function names.
Clarify the octet form.
Add documentation for EC_POINT_oct2buf().
Reviewed-by: Rich Salz <rsalz@openssl.org>
In EC_KEY_priv2buf(), check for pbuf sanity.
If invoked with NULL, gracefully returns the key length.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
- In error paths, EVP_MD_CTX allocated by the callee is not released.
- Checking method before accessing
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
We are using strcmp() as the cmp_func, where in the EDK2 environment
strcmp actually ends up being the external AsciiStrCmp() function —
an EFI library function defined with the Microsoft ABI.
This means that we can't just assign function pointers to it, since
in GCC-hosted builds the ABI of any function *not* explicitly marked
EFIAPI is the native SysV ABI.
Arguably this stupidity ought to be resolved on the UEFI side, but in
the general case that would mean that we need to provide ABI-compatible
wrappers for *all* the "standard" functions, just in case they're used
like this.
And in fact we already have a workaround here for DEC C. So instead of
playing games with casting function pointers, it's nicer just to use a
simple function to wrap the strcmp() call. That cleans up the DEC C
workaround, *and* it works around the UEFI bogosity at the same time.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
mkdef.pl was issuing the following error:
Use of uninitialized value within %tag in numeric eq (==) at
util/mkdef.pl line 560, <IN> line 92
This was because it was treating a __cplusplus "#ifdef" check as a "tag"
but then skipping over the corresponding "#endif". Therefore after
processing a file it still had "left over" tags from processing the
previous file. It was also getting confused by "#if" checks that didn't
match is pre-defined styles.
Reviewed-by: Richard Levitte <levitte@openssl.org>
They now default to " " as separator, but that can be overridden by
having a hash with parameters as last argument. The only currently
recognised parameter is `separator'.
The special separator `undef' will force the result to become a list
rather than a concatenated string.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The internal |fmtstr| function used in processing a "%s" format string
in the BIO_*printf functions could overflow while calculating the length
of a string and cause an OOB read when printing very long strings.
Additionally the internal |doapr_outch| function can attempt to write to
an OOB memory location (at an offset from the NULL pointer) in the event of
a memory allocation failure. In 1.0.2 and below this could be caused where
the size of a buffer to be allocated is greater than INT_MAX. E.g. this
could be in processing a very long "%s" format string. Memory leaks can also
occur.
These issues will only occur on certain platforms where sizeof(size_t) >
sizeof(int). E.g. many 64 bit systems. The first issue may mask the second
issue dependent on compiler behaviour.
These problems could enable attacks where large amounts of untrusted data
is passed to the BIO_*printf functions. If applications use these functions
in this way then they could be vulnerable. OpenSSL itself uses these
functions when printing out human-readable dumps of ASN.1 data. Therefore
applications that print this data could be vulnerable if the data is from
untrusted sources. OpenSSL command line applications could also be
vulnerable where they print out ASN.1 data, or if untrusted data is passed
as command line arguments.
Libssl is not considered directly vulnerable. Additionally certificates etc
received via remote connections via libssl are also unlikely to be able to
trigger these issues because of message size limits enforced within libssl.
CVE-2016-0799
Issue reported by Guido Vranken.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Simplifies calling code. Also fixed up any !ptr tests that were
nearby, turning them into NULL tests.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Fixes github issue 463. Building the app without OPENSSL_NO_SOCK
isn't supported, so only do OPENSSL_NO_OCSP.
Reviewed-by: Andy Polyakov <appro@openssl.org>
