| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
My read of this: Long time ago (Think Conan, not dinasaurs) during the race
to make speedier processors, a cpu vendor built a pipeline with a bad stall,
and proposed a tremendously hasky workaround. A wizard adopted this into his
perl scroll, and failed to reflect later when no compiler adopted the practice.
This relic remains at the tail end of some functions in OpenSSL as
".byte 0xf3,0xc3". Banish it straight to hell.
ok mlarkin, others also stared blankly
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
spotted by doctor jsing, always keeping an eye out for these
|
| |
|
|
|
|
| |
https://www.openssl.org/~appro/camellia/dist/BSD_license.txt
It isn't our concern to supply the other licences mentioned in source
files; that is realy not our problem.
|
| |
|
|
|
|
|
| |
scripts. We certainly do not need an identical copy of the win64
exception handler in each script (surely one copy would be sufficient).
ok miod@
|
| | |
|
| | |
|
| | |
|
| |
|
