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

Even though AVX support was added in GAS 2.19 vpclmulqdq was apparently
added in 2.20.
Reviewed-by: NRich Salz <rsalz@openssl.org>

RT#4323
Reviewed-by: NRich 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: NRich Salz <rsalz@openssl.org>

Now that BIO_sock_nbio is available, use it in the apps.
Reviewed-by: NRichard 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: NRichard Levitte <levitte@openssl.org>

We don't want recipes for the same files generated more than once
Reviewed-by: NRich Salz <rsalz@openssl.org>

Linux target that does that.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

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

Reviewed-by: NRich 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: NRich Salz <rsalz@openssl.org>

The ubsec engine is now considered obsolete and therefore has been
removed.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

This reverts commit acae59bb.
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

They're too slow.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

Since the configs were remade into hash tables, this isn't needed
any more.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

In EC_KEY_priv2buf(), check for pbuf sanity.
If invoked with NULL, gracefully returns the key length.
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

- In error paths, EVP_MD_CTX allocated by the callee is not released.
- Checking method before accessing
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich 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: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Reviewed-by: NMatt 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: NRichard Levitte <levitte@openssl.org>

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

build.info needed a slight update, one more include directory.
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt 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: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NRichard 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: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Simplifies calling code.  Also fixed up any !ptr tests that were
nearby, turning them into NULL tests.
Reviewed-by: NRichard Levitte <levitte@openssl.org>