| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
- Use BIO_new_fp() instead of BIO_new()/BIO_set_fp() and handle NULL
return value in a more appropriate manner.
- Use stroul() instead of sscanf() with appropriate error checking.
ok doug@
|
|
|
|
| |
ok bcook@ doug@
|
|
|
|
|
|
|
|
| |
i2d_X509_PKEY is a "needs to implement" and d2i_X509_PKEY is broken.
Removed upstream in commit b1f3442857c1fd76e91941141bf671d19e90a79d.
ok deraadt@, jsing@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issetugid() API is supposed to make a strong promise where "0
means it is safe to look at the environment". Way back in the past
someone on the OpenSSL team responded to the environment access danger
by creating a wrapper called OPENSSL_issetugid, and went to use it a
number of places. However, by default on systems lacking true
issetugid(), OPENSSL_issetugid returns 0. 0 indicating safely. False
safety. Which means OPENSSL_issetugid() fails to make any sort of
promise about safety, in fact it is just the opposite.
Can you believe the OpenSSL team?
This nastiness was noticed over the years, however noone could gain traction
and get it fixed in OpenSSL. Also see a paragraph about this in
http://www.tedunangst.com/flak/post/worst-common-denominator-programming
ok jsing
|
|
|
|
|
|
|
|
|
| |
getenv()'s wrapped by issetugid() are safe, but issetugid() is correct
difficult to impliment on many operating systems. By accident, a grand
experiment was run over the last year, where issetugid() returned 1 (the
safe value) on a few operating systems. Noone noticed & complained that
certain environment variables were not working.......
ok doug beck jsing, discussion with others
|
|
|
|
| |
Spotted by doug@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
unregistering callbacks if the DSO is unloaded. Move the callback
handling from libpthread to libc, though libpthread still overrides the
inner call to handle locking and thread-library reinitialization.
Major version bump for both libc and libpthread.
verification that this fixes various ports ajacoutot@
asm assistance miod@; ok millert@ deraadt@
|
| |
|
|
|
|
|
| |
instead of simply zapping it. this can save many syscalls in a program
that repeatedly grows and shrinks a buffer, as observed in the wild.
|
|
|
|
|
|
|
| |
(POSIX is fixing its description: readdir_r() was a botch)
Patch from Carlos Mart�n Nieto (cmn (at) dwim.me)
no -portable concerns bcook@
|
| |
|
|
|
|
|
|
| |
close the connection. Also correctly handle the error on failure.
Diff from cookieandscream via github.
|
|
|
|
|
|
| |
Diff from Tim van der Molen.
ok jmc@
|
|
|
|
|
|
| |
TLS_READ_AGAIN and TLS_WRITE_AGAIN.
Based on a diff from Tim van der Molen.
|
| |
|
|
|
|
|
|
| |
accepted via an existing pair of file descriptors.
Based on a diff from Jan Klemkow.
|
|
|
|
|
|
|
| |
compile time, which we do not do and are unlikely to ever do. Additionally,
there are two runtime configurable alternatives that exist.
ok bcook@ doug@
|
|
|
|
|
|
|
| |
for the server, rather than on the context for the connection. This makes
more sense than the current behaviour does.
Issue reported by Tim van der Molen.
|
| |
|
|
|
|
|
|
| |
in four different places.
ok doug@ guenther@
|
| |
|
|
|
|
|
|
|
|
|
| |
socket becomes invalid between these calls (e.g. connection closed), write
will throw SIGPIPE. With this patch, SIGPIPE is ignored so we can
handle write's -1 return value (errno will be EPIPE). Ultimately, it leads
to program exit, too -- but with nicer error message. :)
with input by and ok djm
|
|
|
|
| |
ok djm
|
|
|
|
| |
ok djm
|
|
|
|
| |
ok djm
|
|
|
|
|
|
|
| |
Instead, silently ignore the fact and instead let the underlying
ssh (or $RSH) command handle it.
ok millert@
|
|
|
|
|
|
|
| |
end-of-file, returning 0, in order not to print an unrelated
strerror(errno) in the latter case
ok millert@
|
| |
|
|
|
|
|
|
|
|
|
| |
functions, and ocsp and s_time need networking enabled too, this just moves
BIO_sock_init() up into main() as a catch-all for all of the commands.
Of course, it is a no-op on any other platform.
ok @guenther
|
|
|
|
| |
ok millert@ jung@
|
|
|
|
| |
repeated use of tls_connect. ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The actual control flow is intentional while the indenting is incorrect.
This is intended to be a cosmetic change.
Verified that each of these was part of a KNF commit that wasn't intending
to change behavior. Also, double checked against the history of changes in
OpenSSL and BoringSSL.
Addresses Coverity CIDs: 78842, 78859, 78863.
ok tedu@
|
|
|
|
|
|
| |
From OpenSSL commit 5e5d53d341fd9a9b9cc0a58eb3690832ca7a511f.
ok guenther@, logan@
|
|
|
|
| |
ok todd@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These include:
CVE-2015-0209 - Use After Free following d2i_ECPrivatekey error
CVE-2015-0286 - Segmentation fault in ASN1_TYPE_cmp
CVE-2015-0287 - ASN.1 structure reuse memory corruption
CVE-2015-0289 - PKCS7 NULL pointer dereferences
Several other issues did not apply or were already fixed.
Refer to https://www.openssl.org/news/secadv_20150319.txt
joint work with beck, doug, guenther, jsing, miod
|
|
|
|
|
|
|
|
|
|
|
| |
routines on hppa, the cause for sha512-parisc subtly misbehaving has been
found: despite having fallback pa1.1 code when running on a 32-bit cpu, the
shift constants used in the sigma computations in sha512 are >= 32 and are
silently truncated to 5 bits by the assembler, so there is no chance of
getting this code to work on a non-pa2.0 processor.
However, the pa1.1 fallback code for sha256 is safe, as it never attempts to
shift by more than 31, so reenable it again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A NULL pointer could be dereferenced when X509_REQ_set_pubkey() calls
X509_PUBKEY_set() with pktmp.
OpenSSL says it's the fix for CVE-2015-0288, but there aren't any public
details yet to confirm. Either way, we should fix this.
Based on OpenSSL commit 28a00bcd8e318da18031b2ac8778c64147cd54f9
and BoringSSL commit 9d102ddbc0f6ed835ed12272a3d8a627d6a8e728.
"looks sane" beck@
ok miod@, bcook@
|
|
|
|
|
|
|
|
| |
fail), on 64-bit systems.
tested on 64-bit (amd64) and 32-bit (sparc).
OK claudio@ deraadt@
|
|
|
|
|
| |
for overflow. stop talking about old broken systems, there's little use
for such info.
|
|
|
|
| |
spotted by miod. ok miod.
|
|
|
|
|
| |
by a similar BoringSSL change, but raising the limit to 1024 bits.
ok jsing@ markus@ guenther@ deraadt@
|
|
|
|
|
|
|
|
|
|
|
| |
regress tests but causes tls ciphersuite using sha386 to fail; found the
hard way by henning@.
I can't see anything wrong in the generated assembly code yet, but building
a libcrypto with no assembler code but sha512_block_data_order() is enough
to trigger Henning's issue, so the bug lies there.
No ABI change; ok deraadt@
|
|
|
|
|
| |
to place in an int. from Christian Neukirchen
ok deraadt
|
| |
|
|
|
|
|
|
|
|
|
| |
an additional 28 bytes of .rodata (or .data) is provided to the network. In
most cases this is a non-issue since the memory content is already public.
Issue found and reported by Felix Groebert of the Google Security Team.
ok bcook@ beck@
|
|
|
|
| |
ok jsing@
|
|
|
|
|
|
|
|
|
|
|
| |
Predefined strings are not very portable across troff implementations,
and they make the source much harder to read. Usually the intended
character can be written directly.
No output changes, except for two instances where the incorrect escape
was used in the first place.
tweaks + ok schwarze@
|
|
|
|
|
|
| |
them guaranteed to not conflict per POSIX.
ok espie@ guenther@
|
|
|
|
| |
OK guenther@
|