| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.
This also includes some miscellaneous sorting/tidying of headers.
|
|
|
|
|
|
| |
are needed in the source files that actually require them.
ok beck@ miod@
|
|
|
|
| |
ok miod@ deraadt@ guenther@
|
|
|
|
| |
Substantially expand the conditional to reduce potential for error.
|
|
|
|
| |
ok miod
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
collateral damage.
The syncronous nature of this mechanism has hampered performance for
symmetric crypto relative to brute-force cpu. The assymetric crypto
support never really materialized in drivers.
So abandon the complexity.
ok tedu beck mikeb
some disagrement from djm but if he wants to test /dev/crypto ciphers
he should do it without this this gigantic API in the way
|
| |
|
| |
|
| |
|
|
|
|
| |
ok miod
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the intel RDRAND instruction. Consensus was RDRAND should probably
only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to
RDRAND? Yep. Guess which applications are using this support? Not
even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss.
ok kettenis
|
|
|
|
| |
ok tedu guenther
|
| |
|
|
|
|
|
|
|
|
|
| |
potential integer overflows easily changed into an allocation return
of NULL, with errno nicely set if need be. checks for an allocations
returning NULL are commonplace, or if the object is dereferenced
(quite normal) will result in a nice fault which can be detected &
repaired properly.
ok tedu
|
|
|
|
| |
eyeballed before applying. Contributed by Cyril Roelandt on tech@
|
|
|
|
|
|
| |
libssl tree from all uses of these defines.
ok miod@
|
|
|
|
| |
ok miod@
|
|
|
|
|
| |
makes this compile with OPENSSL_NO_DEPRECATED defined.
ok deraadt@
|
|
|
|
|
|
|
|
| |
Also check for _LP64 rather than __arch64__ (the former being more reliable
than __LP64__ or __arch64__) to tell 64-bit int platforms apart from 32-bit
int platforms.
Loosely based upon a diff from Martijn van Duren on tech@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
avoid unreadable/unmaintainable constructs like that:
const EVP_PKEY_ASN1_METHOD cmac_asn1_meth =
{
EVP_PKEY_CMAC,
EVP_PKEY_CMAC,
0,
"CMAC",
"OpenSSL CMAC method",
0,0,0,0,
0,0,0,
cmac_size,
0,
0,0,0,0,0,0,0,
cmac_key_free,
0,
0,0
};
ok matthew@ deraadt@
|
|
|
|
|
| |
declaration to pass -Wextra, should we want to add it to CFLAGS.
No binary change.
|
|
|
|
|
|
|
|
| |
This avoids a lot of ugly gymnastics to do snprintfs before sending the
bag of strings to ERR, and eliminates at least one place in dso_dlfctn.c
where it was being called with the incorrect number of arguments and
using random things off the stack as addresses of strings.
ok krw@, jsing@
|
|
|
|
| |
ok miod@
|
| |
|
|
|
|
|
|
| |
truncation is either desirable, not an issue, or is detected and handled later
ok deraadt@
|
|
|
|
| |
ok miod
|
| |
|
|
|
|
| |
ok tedu@
|
|
|
|
|
|
|
|
| |
OPENSSL_foo wrappers. This changes:
OPENSSL_malloc->malloc
OPENSSL_free->free
OPENSSL_relloc->realloc
OPENSSL_freeFunc->free
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
"dynamic engine" feature that is not enabled in our build. People who
need it can still pull it out of the Attic; if it is to have a Russian
engine just because it's a Russian engine.
OK deraadt@ beck@
|
|
|
|
|
| |
where the return value is ignored changing to (void) snprintf.
ok deraadt@
|
|
|
|
|
|
|
| |
undo the move of crypto/engines/eng_padlock to engines/e_padlock.
Requested by reyk@.
Note that eng_padlock is not compiled in currently.
|
|
|
|
|
| |
that it is easier to find code pieces. They are getting in the way.
ok miod
|
|
|
|
|
|
|
| |
an alternative backend for BIGNUM calculations. It is PoC code that
is not enabled in OpenSSL and probably not used by anymore.
ok deraadt@
|
|
|
|
|
|
| |
could be maintained in an external package.
"it should probably go" beck@
|
|
|
|
| |
FPGA-based device is long obsolete.
|
|
|
|
| |
external libraries that aren't covered by the same license.
|
| |
|
|
|
|
|
|
|
|
|
| |
relevant anymore. OpenSSL should have a better way to include 3rd
party engines: either completely and free or external. But including
a wrapper for a non-free wrapper in the code base does not make much
sense and could also be provided by the vendor.
ok deraadt@
|
|
|
|
|
|
|
|
|
| |
non-free libraries. OpenSSL should have a better way to include 3rd
party engines: either completely free or external. But including a
wrapper for a non-free wrapper in the code base does not make much
sense and could also be provided by the vendor.
ok deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hardware.
The vendor_defns/cswift.h does not specify a copyright and
theoretically defaults to the OpenSSL license, but it also mentions
that it includes parts that have been "clipped" from CryptoSwift's
proprietary headers. This file should better include an explicit
copyright statement or mention OpenSSL's library instead of the
ambiguous "Attribution notice".
ok deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vendor_defns/sureware.h file by Baltimore Technologies Ltd. has a
copyright that does not grant rights!
Vendor files should either include a compatible license in the
copyright statement or use OpenSSL's defaults, but adding a copyright
statement without any terms is not acceptable. It should not have
been included in the first place.
ok deraadt@
|