| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
on amd64 only for now. Stanzas to enable it on arm, i386 and sparc64 are
provided but commented out for lack of testing due to the machine room
being currently in storage.
ok jsing@
|
|
|
|
|
|
|
| |
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.
ok tom@ bcook@
|
|
|
|
|
|
|
| |
We do not build, test or ship any dynamic engines, so we can remove the dynamic
engine loader as well. This leaves a stub initialization function in its place.
ok beck@, reyk@, miod@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
probably ok beck jsing miod
|
|
|
|
|
| |
can know...
ok jsing@
|
|
|
|
|
| |
Note that GCM128 Neon code is currently not built (and thus not tested), as
the current toolchain does not support Neon instructions.
|
| |
|
| |
|
|
as configuration files; split manpages and .pc files between libcrypto and
libssl.
No functional change, only there to make engineering easier, and libcrypto
sources are still found in libssl/src/crypto at the moment.
ok reyk@, also discussed with deraadt@ beck@ and the usual crypto suspects.
|