| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
be enabled, mostly since people use SANs instead.
ok beck@ guenther@
|
| |
|
|
|
|
|
|
| |
be enabled.
Removes one symbol from libcrypto, however there is no ABI change.
ok beck@ miod@ tedu@
|
| |
|
|
|
|
|
| |
This code is not compiled in and OPENSSL_NO_STORE is already defined in
opensslfeatures.h. No symbol removal for libcrypto.
ok beck@
|
| |
|
|
|
|
|
| |
this split across files, especially when two of them have less code than
license text.
ok bcook@ beck@ doug@ miod@
|
| |
|
|
|
|
|
|
|
|
|
| |
instead of disk. OpenSSL didn't provide a built-in API from loading
certificates in a chroot'ed process that doesn't have direct access to
the files. X509_STORE_load_mem() provides a new backend that will be
used by libssl and libtls to implement such privsep-friendly
functionality.
Adopted for LibreSSL based on older code from relayd (by pyr@ and myself)
With feedback and OK bluhm@
|
| |
|
|
|
|
|
|
|
| |
Several functions that need to be redefined for a Windows port are right
in the middle of other code that is relatively portable. This patch
isolates the functions that need Windows-specific implementations so
they can be built conditionally in the portable tree.
ok jsing@ deraadt@
|
| |
|
|
| |
Makefile.inc (i.e. landisk and m88k)
|
| |
|
|
| |
libcrypto minor bump.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There used to be a strong reluctance to provide this cipher in LibreSSL in the
past, because the licence terms under which Cammelia was released by NTT were
free-but-not-in-the-corners, by restricting the right to modify the source
code, as well retaining the right to enforce their patents against anyone
in the future.
However, as stated in http://www.ntt.co.jp/news/news06e/0604/060413a.html ,
NTT changed its mind and made this code truly free. We only wish there had
been more visibility of this, for we could have had enabled Cammelia
earlier (-:
Licence change noticed by deraadt@. General agreement from the usual LibreSSL
suspects.
Crank libcrypto.so minor version due to the added symbols.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
engine to regular EVP citizens, contributed by Dmitry Eremin-Solenikov;
libcrypto bits only for now.
This is a verbatim import of Dmitry's work, and does not compile in this
state; the forthcoming commits will address these issues.
None of the GOST code is enabled in libcrypto yet, for it still gets
compiled with OPENSSL_NO_GOST defined. However, the public header gost.h
will be installed.
|
| |
|
|
|
|
|
|
|
|
|
| |
the details are under embargo. The original plan was to wait for the
embargo to lift, but we've been waiting for quite some time, and there's no
indication of when or even if it will end. No sense in dragging this out
any longer.
The SRP code has never been enabled in OpenBSD, though I understand it is
in use by some other people. However, in light of this and other issues,
we're officially saying SRP is outside the scope of libressl. (For now.)
|
| |
|
|
| |
done for other symmetric algorithms recently.
|
| |
|
|
| |
probably ok beck jsing miod
|
| |
|
|
|
|
|
|
| |
compiled-in, with nonfunctional code, to be able to cope with the RSA
patent.
However, we don't use this option, and the RSA patent has expired more than 10
years ago, so just drop this piece.
|
| |
|
|
|
|
|
| |
which had never been installed, so it's unlikely something ever used this
in the last 15~20 years.
ok deraadt@ jsing@ beck@
|
| |
|
|
|
| |
should not know anything about. Verified not to be used in ports; riding upon
the recent libcrypto major bump.
|
| |
|
|
| |
ok beck
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 beck
|
| |
|
|
|
|
|
|
|
|
|
| |
more #ifdefs and a new source file that contains a single function.
Nuke the #if 0 code that is now a macro and move the single function in
evp_acnf.c to c_all.c, which is where the other code lives. While here,
tidy evp.h slightly, remove an unnecessary #ifdef __OpenBSD__ and nuke
a comment that is now a lie.
ok miod@
|
| |
|
|
|
|
| |
Langley's Chromium OpenSSL patches.
ok miod@
|
| |
|
|
|
|
|
| |
implementations. This largely pulls in Adam Langley's AEAD patches from
Chromium's OpenSSL.
ok miod@
|
| |
|
|
|
|
| |
implementation.
ok miod@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
of 64-bit data, and only used by DTLS, to libssl where it belongs.
Remove pqueue_print() which is a debugging interface and serves no useful
purpose, except for the regress test, which grows its own pqueue_print()
routine.
Bump libcrypto major and libssl minor.
WARNING: do not update your tree right now, more changes are coming, which
will ride the libcrypto major bump.
|
| |
|
|
|
| |
or the !SSLASM list of files applies. This allows for an arch-specific
Makefile.inc to not specify SSLASM.
|
| | |
|
| |
|
|
| |
ok deraadt@
|
| |
|
|
| |
ok miod@
|
| |
|
|
| |
ok miod@
|
| |
|
|
|
|
|
| |
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@
ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'
|
| |
|
|
|
|
|
| |
are still some 3rd-party code using it, and fixing them is not trivial.
As an excuse gift, the memory leaks on failure in resurrected a_set.c have
been fixed.
|
| |
|
|
| |
ok deraadt
|
| |
|
|
| |
ok deraadt.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had
to be convoluted enough for the compiler not to recognize that this was
actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse()
is beyond me. Did someone not trust the C obfuscation?
|
| |
|
|
|
|
| |
fragments, to ease maintainance, and see through the fog of bugs.
"looks good" deraadt@
|
| |
|
|
|
|
| |
free software project. ok beck deraadt
Ports calling FIPS_mode_set(1): mongodb
|
| |
|
|
| |
gets a second trim.
|
| |
|
|
| |
now removed engines.
|
| |
|
|
|
|
| |
of des_old.h routines, acting as wrappers about the OpenSSL UI API.
Nothing should use these functions directly.
Riding the recent libcrypto major bump (in a `des' car).
|
| |
|
|
|
|
|
|
| |
are not please fix your operating system. Replace mem.c with an API-compatible
wrapper that just calls the system functions and does not allow a one word
modification of a variable in a running shared library to turn on memory
debug functions that expose things that should not be seen.
ok tedu@
|
| |
|
|
| |
ok beck deraadt
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The man page says "Compatibility des_ functions are provided for a short
while" and indeed even the original commit message says "The compatibility
functions will be removed in some future release, at the latest in
version 1.0." So here we are, a short while later.
Now I've only been an OpenBSD developer for 11 years, one year less than
this header has existed, but in that brief time, I've learned a thing or
two about deleting obsolete code. It doesn't delete itself. And worse,
people will continue using it until you force them onto a better path.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
with the bearded ones...
some API's that nobody should be using will dissapear with this commit.
|
| |
|
|
|
| |
as a build time option...
ok deraadt@ miod@
|