| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
next few moments, don't rush your update.
Requested by deraadt@
|
|
|
|
|
|
|
|
|
|
| |
obsolete (and mostly internal) routines to be compiled out.
We don't expect any reasonable software to stick to these interfaces, so better
clean up the view and unifdef -DNO_ASN1_OLD.
The astute reader will notice the existence of NO_OLD_ASN1 which serves a
similar purpose, but is more entangled. Its time will come, soon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
library expands until it has its own dlfcn wrapper, and libcrypto is no
exception.
Remove the non-dlfcn DSO methods.
This causes public DSO_METHOD_{beos,dl,vms,win32} to disappear (major bump
coming soon). Note that portable software ought to use DSO_METHOD_openssl
instead of picking the backend directly (which makes one wonder why the
backends are exposed, as it is unlikely that more than one can work on
your system).
ok beck@ deraadt@
|
|
|
|
|
| |
meets their needs, but dumping it in here only penalizes the rest of us.
ok beck deraadt
|
| |
|
|
|
|
|
| |
before attempting to invoke it; trivial one-liner in OpenSSL RT #2569 ignored
for 2.5 years.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
"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@
|
|
|
|
|
| |
with the bearded ones...
some API's that nobody should be using will dissapear with this commit.
|
|
|
|
| |
ok miod@
|
|
|
|
|
| |
readable. This pass is whitespace only and can readily be verified using
tr and md5.
|
|
|
|
|
| |
as a build time option...
ok deraadt@ miod@
|
|
|
|
| |
ok miod@ beck@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
existing RAND interfaces unchanged.
All interfaces allowing external feed or seed of the RNG (either from a file
or a local entropy gathering daemon) are kept for ABI compatibility, but are
no longer do anything.
While the OpenSSL PRNG was required 15+ years ago when many systems lacked
proper entropy collection, things have evolved and one can reasonably assume
it is better to use the kernel (system global) entropy pool rather than trying
to build one's own and having to compensate for thread scheduling...
<RANT>
Whoever thought that RAND_screen(), feeding the PRNG with the contents of the
local workstation's display, under Win32, was a smart idea, ought to be banned
from security programming.
</RANT>
ok beck@ deraadt@ tedu@
|
|
|
|
|
|
| |
the wrong place and it will need heavy lifting. Love the .bat files
and the reference to pre-draft pthreads code at MIT.
ok beck
|
|
|
|
|
| |
readable. This pass is whitespace only and can readily be verified using
tr and md5.
|
|
|
|
|
| |
where the return value is ignored changing to (void) snprintf.
ok deraadt@
|
|
|
|
|
| |
readable. This pass is whitespace only and can readily be verified using
tr and md5.
|
|
|
|
|
| |
readable. This pass is whitespace only and can readily be verified using
tr and md5.
|
|
|
|
| |
ok miod@
|
|
|
|
| |
ok miod@ guenther@
|
|
|
|
| |
(breaks ssh ecdsa keys)
|
|
|
|
|
|
|
| |
undo the move of crypto/engines/eng_padlock to engines/e_padlock.
Requested by reyk@.
Note that eng_padlock is not compiled in currently.
|
| |
|
|
|
|
|
|
| |
early attempt at getting kernel-assisted crypto(4) used by libcrypto, before
the engine API existed, and has been #if 0'd out for ages anyway.
No API/ABI change.
|
|
|
|
|
|
|
| |
in a bunch of places inside the TLS engine, to try to keep entropy high.
I wonder if their moto is "If you can't solve a problem, at least try
to do it badly".
ok miod
|
|
|
|
|
| |
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@
|
|
|
|
| |
makes sense to beck@
|
|
|
|
| |
FPGA-based device is long obsolete.
|
|
|
|
| |
external libraries that aren't covered by the same license.
|
|
|
|
|
|
| |
#if OPENSSL_SYS_NOTYOURS
<whole file>
#endif
|
| |
|
|
|
|
| |
ok beck deraadt
|
| |
|
|
|
|
|
|
| |
which did shutdown + close, all nasty and surprising. Use the raw
syscalls that everyone knows the behaviour of.
ok beck matthew
|
|
|
|
| |
ok deraadt@
|
|
|
|
| |
ok deraadt@
|
|
|
|
| |
ok deraadt@
|
|
|
|
| |
ok miod@ deraadt@
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vendor_defns/hw_ubsec.h file 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.
(The ubsec(4) kernel driver is not affected by this change)
ok deraadt@
|
|
|
|
|
|
| |
old PCI accelerator that was EOL'ed in 2005.
ok deraadt@
|
| |
|
|
|
|
| |
by anything in userland.
|