Would be nice to document when/where this originated (in glibc?) if
anyone knows...
tweaks by schwarze@
ok jmc@ espie@ kettenis@ schwarze@ dimitry(at)google.com
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.
often space-constrained /var filesystem was a historical mistake. There
are big implications for the daemons which assume they won't run out of
space, and this is a first step towards trying to improve the situation.
Move /tmp to the same 7-day expiration rules that /var/tmp had.
vi.recover works just as well as before, except on memory filesystems;
indicating that vi should be repaired to write files into homedirs or
something.
done with rpe
ok many
troff displays these as typographic quotes, but nroff implementations
almost always print them literally, which rarely has the intended effect
with modern fonts, even in stock xterm.
These uses of `` '' can be replaced either with more semantic alternatives
or with Dq, which prints typographic quotes in a UTF-8 locale (but will
automatically fall back to `` '' in an ASCII locale).
improvements and ok schwarze@
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.
This functionality was already available (and optional), and used in the
bowels of the ASN.1 code. This exposes it as a public interface, which will
be used by the upcoming GOST code.
Crank libcrypto minor version.
From Dmitry Eremin-Solenikov.
The FreeBSD-native arc4random_buf implementation falls back to weak sources of
entropy if the sysctl fails. Remove these dangerous fallbacks by overriding
locally.
Unfortunately, pthread_atfork() is also broken on FreeBSD (at least 9 and 10)
if a program does not link to -lthr. Callbacks registered with pthread_atfork()
simply fail silently. So, it is not always possible to detect a PID wraparound.
I wish we could do better.
This improves arc4random_buf's safety compared to the native FreeBSD
implementation.
Tested on FreeBSD 9 and 10.
relevant example snippet in the relayd.conf(5) man page.
Change the default SSL protocols in the example file/man page to
"no tlsv1.0" (suggested by sthen@), which will enable the TLSv1.1
and TLSv1.2 protocols only.
feedback/ok jsing@ reyk@ sthen@
The old man page had a lot of useful information, but it was all mixed
together which made it difficult to reference. The main theme in this
commit is that the sections are more focused:
* DESCRIPTION describes the overall behavior
* RETURN VALUES describes what it may return (including implementation
defined values)
* EXAMPLES shows why we recently started an audit on malloc and realloc
usage in the tree.
* Added CAVEATS which describes what is implementation defined, gotchas
and security implications of misusing these functions
* Added IDIOMS which describes how these functions should or
should not be used
The MALLOC_OPTIONS section was left unchanged. Function names were
added to DIAGNOSTICS and STANDARDS. The MALLOC_OPTIONS and DIAGNOSTICS
sections were pushed down in the page so more pertinent information is
higher up.
This has gone through several revisions thanks to input from deraadt@
and schwarze@. Ingo also helped with some of the mandoc formatting.
OK schwarze@ (as far as it is a good starting point and the code
snippets look ok)
in case something wants to create massive amounts of environment, like
a bit more than 1/4 of a 32-bit address space. unrealistic -- but why
audit one code path, and not treat others the same? then you have to
re-engage everytime you see the code. read the news, that isn't what
developers do. At least if the code paths look the same, there is hope,
because they are easier to verify for correctness. developers need
to give other developers a chance to want to care.
deraadt