| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
that use these algorithms (and SEED was removed from libcrypto some time
ago).
ok doug@
|
| |
|
| |
|
|
|
|
| |
Based on OpenSSL.
|
|
|
|
| |
there are backwards compatible names/aliases for EDH.
|
|
|
|
|
| |
drafts are now RFCs. Also add the TLS extension type for ALPN and be
consistent with RFC reference formatting.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This allows an SSL server to enable DHE ciphers with a single setting,
which results in an DH key being generated based on the server key length.
Partly based on OpenSSL.
|
|
|
|
|
|
|
|
|
| |
The only use for these is via SSL_OP_EPHEMERAL_RSA (which is effectively
a standards violation) and for RSA sign-only, should only be possible if
you are using an export cipher and have an RSA private key that is more
than 512 bits in size (however we no longer support export ciphers).
ok bcook@ miod@
|
| |
|
|
|
|
|
|
| |
distinguish between LibreSSL (the project) and libressl (the library).
Discussed with many.
|
| |
|
|
|
|
|
| |
don't want to give people the idea that this is non-portable (it
has been present since C89). OK deraadt@ schwarze@
|
|
|
|
| |
would be the next stage of embiggening. restore 16k.
|
|
|
|
|
| |
if one pipe stalls out. from a diff by Arne Becker.
(buffer size left alone for now)
|
|
|
|
| |
ok jsing@ miod@
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
POLLHUP too. OK deraadt@
|
|
|
|
|
|
| |
programs.
ok deraadt@ millert@
|
|
|
|
|
|
| |
Suggested by millert@ and schwarze@.
OK schwarze@, millert@
|
|
|
|
|
| |
of p12->mac->salt->data has actually succeeded.
In one of my trees for a long time already...
|
|
|
|
|
|
|
|
| |
SSL3_RT_HANDSHAKE replays.
Reported by Markus Stenberg <markus.stenberg at iki.fi> - thanks!
ok deraadt@
|
| |
|
|
|
|
| |
are still needed for the engine). Our code should use arc4random instead.
|
|
|
|
| |
ok bcook@
|
| |
|
|
|
|
| |
with unchecked return values).
|
| |
|
|
|
|
|
|
|
|
| |
arc4random_buf() is guaranteed to always succeed - it is worth noting
that a number of the replaced function calls were already missing return
value checks.
ok deraadt@
|
|
|
|
| |
ok deraadt@
|
|
|
|
|
| |
Remove excessive technicalities on zero-sized objects as suggested by deraadt@.
contributions and ok deraadt@, ok jmc@ on an earlier version
|
|
|
|
|
|
|
|
| |
Modified patch from Dmitry Eremin-Solenikov
leave the sole public define in ripemd.h
ok deraadt@ miod@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified version of patch from Dmitry Eremin-Solenikov.
==28360== 98 bytes in 2 blocks are definitely lost in loss record 7 of 7
==28360== at 0x402AC54: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==28360== by 0x40E2D2C: ASN1_STRING_set (asn1_lib.c:393)
==28360== by 0x40EC22C: asn1_ex_c2i (tasn_dec.c:959)
==28360== by 0x40EC632: asn1_d2i_ex_primitive (tasn_dec.c:824)
==28360== by 0x40ED2E6: ASN1_item_ex_d2i (tasn_dec.c:230)
==28360== by 0x40ED421: ASN1_item_d2i (tasn_dec.c:133)
==28360== by 0x40F0335: d2i_ASN1_OCTET_STRING (tasn_typ.c:75)
==28360== by 0x405FD6D: d2i_SSL_SESSION (ssl_asn1.c:367)
==28360== by 0x405DD6E: ssl3_send_newsession_ticket (s3_srvr.c:2743)
==28360== by 0x405EA48: ssl3_accept (s3_srvr.c:665)
==28360== by 0x4067C34: SSL_accept (ssl_lib.c:922)
==28360== by 0x404E97B: ssl23_get_client_hello (s23_srvr.c:573)
ok miod@ beck@
|
|
|
|
|
| |
from Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
ok beck@, deraadt@
|
|
|
|
|
| |
and fix two instances of "new sentence, new line" while here
feedback and ok jmc@, ok doug@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
| |
millert@ made changes to realpath.c based on FreeBSD's version. I merged
Todd's changes into dl_realpath.c.
ok millert@, guenther@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arc4random provides high quality pseudo-random numbers, hence there is no
need to differentiate between "strong" and "pseudo". Furthermore, the
arc4random_buf() function is guaranteed to succeed, which avoids the need
to check for and handle failure, simplifying the code.
It is worth noting that a number of the replaced RAND_bytes() and
RAND_pseudo_bytes() calls were missing return value checks and these
functions can fail for a number of reasons (at least in OpenSSL -
thankfully they were converted to wrappers around arc4random_buf() some
time ago in LibreSSL).
ok beck@ deraadt@ miod@
|
|
|
|
| |
ok deraadt@
|
| |
|
| |
|
|
|
|
|
| |
intrinsic functions everywhere, and wrap these functions in an
#ifndef LIBRESSL_INTERNAL to make sure we don't bring their use back.
|
|
|
|
|
|
|
| |
support the protocols of the future.
(Perhaps a bit late in burning this bridge entirely, but there's no time
like the present, esp. with other players now leaning against back compat.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSLv3 has been long known to have weaknesses and the POODLE attack has
once again shown that it is effectively broken/insecure. As such, it is
time to stop enabling a protocol was deprecated almost 15 years ago.
If an application really wants to provide backwards compatibility, at the
cost of security, for now SSL_CTX_clear_option(ctx, SSL_OP_NO_SSLv3) can be
used to re-enable it on a per-application basis.
General agreement from many.
ok miod@
|
| |
|