Reviewed-by: Andy Polyakov <appro@openssl.org>

Even though AVX support was added in GAS 2.19 vpclmulqdq was apparently
added in 2.20.

Reviewed-by: Rich Salz <rsalz@openssl.org>

RT#4323

Reviewed-by: Rich Salz <rsalz@openssl.org>

Add some missing parentheses and reformat.

Document EC_KEY_oct2key(), EC_KEY_key2buf(), EC_KEY_oct2priv(),
EC_KEY_priv2oct() and EC_KEY_priv2buf()

Reviewed-by: Rich Salz <rsalz@openssl.org>

Now that BIO_sock_nbio is available, use it in the apps.

Reviewed-by: Richard Levitte <levitte@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>

We don't want recipes for the same files generated more than once

Reviewed-by: Rich Salz <rsalz@openssl.org>

Linux target that does that.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

MR: #2083

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>

The ubsec engine is now considered obsolete and therefore has been
removed.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

This reverts commit acae59bb

.

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

They're too slow.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Since the configs were remade into hash tables, this isn't needed
any more.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@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>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@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>

Reviewed-by: Matt Caswell <matt@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>

Reviewed-by: Rich Salz <rsalz@openssl.org>

build.info needed a slight update, one more include directory.

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@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>

Reviewed-by: Richard Levitte <levitte@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>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@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>