| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
| |
See https://www.openssl.org/news/secadv_20150108.txt for a more detailed
discussion.
Original OpenSSL patch here:
https://github.com/openssl/openssl/commit/a7a44ba55cb4f884c6bc9ceac90072dea38e66d0
The regression test is modified a little for KNF.
ok miod@
|
| |
|
|
|
|
| |
Discussed with/requested by deraadt@ at the conclusion of s2k15.
|
| |
|
|
|
|
|
|
|
|
|
| |
BN_bin2bn() will helpfully allocate a BN which is then leaked. Avoid this
by explicitly checking for NULL at the start of the bnrand() function.
Fixes Coverity ID 78831.
ok miod@
|
|
|
|
| |
ok doug@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In dsa_builtin_paramgen(), if BN_MONT_CTX_new() fails, the BN_CTX_new()
call above it will have allocated a ctx without calling BN_CTX_start() on
it. The error handling calls BN_CTX_end() when ctx is allocated.
Move the BN_MONT_CTX_new() call up so it will fail first without splitting
up the BN_CTX_new() and BN_CTX_start().
tweak + ok miod@, ok bcook@
|
| |
|
|
|
|
|
|
|
|
| |
large enough, do it correctly so that the local seed buffer on the stack
gets properly initialized in the first iteration of the loop.
While there, remove an outdated and bogus comment.
Coverity CID 21785
ok doug@ jsing@
|
|
|
|
| |
ok doug@
|
|
|
|
|
| |
all the function's exit paths can make sure it gets freed. Coverity CID 78861
tweaks & ok doug@ jsing@
|
|
|
|
| |
reminded by bcook@
|
| |
|
|
|
|
|
| |
Coverity CID 105346
ok doug@
|
| |
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
ok doug@
|
|
|
|
| |
Only change to generated assembly is due to line numbers.
|
|
|
|
|
|
| |
libcrypto/libssl, and nothing seems to use it in the wild, apart from embedded
copies of OpenSSL.
ok jsing@
|
| |
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
|
| |
ok doug@ jsing@
CVy: Committing in .
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
ok doug@ jsing@
|
|
|
|
| |
ok jsing@
|
|
|
|
| |
ok jsing@
|
|
|
|
|
|
| |
diff.
Spotted by miod@
|
|
|
|
|
|
|
|
|
| |
data structures visible and easier to review, without having to wade
through layers and layers of asn1t.h macros.
Change has been scripted and there is no change to the generated assembly.
Discussed with beck@ miod@ tedu@
|
|
|
|
|
|
|
|
|
| |
data structures visible and easier to review, without having to wade
through layers and layers of asn1t.h macros.
Change has been scripted and there is no change to the generated assembly.
Discussed with beck@ miod@ tedu@
|
|
|
|
|
| |
doug@ and jsing@, ok doug@ three months ago (sigh... I sometimes suck bigtime
at commiting bugfixes)
|
| |
|
|
|
|
|
|
| |
profit of the occasion to start the conversion of
LibreSSL libcrypto manuals from perlpod(1) to mdoc(7).
miod@ jmc@ bentley@ agreed to the process when shown this patch.
|
|
|
|
|
|
| |
initialise during declaration and drop the else statement.
ok doug@ miod@
|
|
|
|
| |
ok tedu@ about 7 months ago and I was sitting upon this diff for no reason
|
|
|
|
|
|
|
| |
This is the same as the previous larger commit, however it would seem the
GOST part got missed.
ok beck@ doug@
|
|
|
|
| |
ok guenther@ jsg@
|
|
|
|
| |
ok doug@
|
|
|
|
|
|
| |
aka ASN1_generate_nconf("FORMAT", NULL)
ok krw@ beck@ jsing@
|