openbsd/src/lib/libcrypto/crypto, branch libressl-v2.2.0A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v2.2.02015-05-17T22:39:39+00:00Record inter-library dependencies between libcrypto, libssl and libtls2015-05-17T22:39:39+00:00kettenis2015-05-17T22:39:39+00:00urn:sha1:c5f087c6c031837a968277278b7d6de4ae1692fbNot all Linux libc's include linux/sysctl.h in sys/sysctl.h.2015-04-27T03:37:06+00:00bcook2015-04-27T03:37:06+00:00urn:sha1:29b3e8caf044d209b7dcfe76059033f1e5174a65
Include it if we have the sysctl syscall.
Support AIX versions without WPAR support.2015-04-27T03:34:43+00:00bcook2015-04-27T03:34:43+00:00urn:sha1:218560577e54c8df6beb6f07c4ce700f230c8fe1
From Michael Felt.
Send OPENSSL_issetugid() straight to hell, no final cigarette.2015-04-11T16:16:15+00:00deraadt2015-04-11T16:16:15+00:00urn:sha1:01d65208fd8dd61fb0f8c5d92ff80c7630a7c2b5
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
add initial AIX getentropy/arc4random files. Thanks to Michael Felt.2015-03-30T11:29:48+00:00bcook2015-03-30T11:29:48+00:00urn:sha1:9a233fbb9c7e0c8634665919ddc8b9da92a7f3c4sys/sysctl.h includes linux/sysctl.h, remove the extra unchecked include2015-03-22T13:28:03+00:00bcook2015-03-22T13:28:03+00:00urn:sha1:2726156be030e091258537fe7ca338f221ab9277In the neverending saga of enabling and disabling assembler code for sha2015-03-18T05:26:10+00:00miod2015-03-18T05:26:10+00:00urn:sha1:6b3d8d3164d1b68d078a0cf83583f3dd8bbcb340
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.
Do not use sha512-parisc for now, as it is subtly bugged - passes the sha2015-03-05T20:35:28+00:00miod2015-03-05T20:35:28+00:00urn:sha1:edab9f054cd9e7b7c2bb8b5683f63e8a6eaea617
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@
Bump libcrypto and libssl majors, due to various recent churn.2015-02-22T16:03:06+00:00jsing2015-02-22T16:03:06+00:00urn:sha1:bb820e160520888599d0966ac5d4a5270c855a23
Discussed with/requested by deraadt@ at the conclusion of s2k15.
unifdef OPENSSL_NO_RFC3779 - this is currently disabled and unlikely to2015-02-10T13:28:17+00:00jsing2015-02-10T13:28:17+00:00urn:sha1:b5dcc59b2cf1dad7e9ebcc08266a1bf71c384886
be enabled, mostly since people use SANs instead.
ok beck@ guenther@