A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v2.3.0 2015-09-13T23:42:29+00:00 2015-09-13T23:42:29+00:00 doug 2015-09-13T23:42:29+00:00 urn:sha1:da36d6a18c187f8d3c2e38a0e5940d8073110b10 2015-09-13T10:02:49+00:00 miod 2015-09-13T10:02:49+00:00 urn:sha1:83f57d181d785f30f940e80aab02506a0ccdffb8 cpu's specific hardware capabilities users of libcrypto might be interested in, as an integer value. This deprecates the existing OPENSSL_ia32cap() macro and the OPENSSL_ia32cap_loc() function (which returns the pointer so that you can mess with stuff you shouldn't mess with). Interpreting the value returned by OPENSSL_cpu_caps() is, of course, machine-dependent. Minor version bump for libcrypto. ok beck@ jsing@ 2015-07-19T22:34:27+00:00 doug 2015-07-19T22:34:27+00:00 urn:sha1:25841ddc7e1d255a907b71bc100b10c363287a75 OpenSSL stopped building it last year and removed it this year. Based on OpenSSL commit c436e05bdc7f49985a750df64122c960240b3ae1. Also cranked major version in libcrypto, libssl and libtls. "fine with me" bcook@ miod@ 2015-06-20T01:09:31+00:00 doug 2015-06-20T01:09:31+00:00 urn:sha1:bedaa1810c5bb6d8b84e1bec8033245abf6e95dc ok miod@ jsing@ 2015-05-17T22:39:39+00:00 kettenis 2015-05-17T22:39:39+00:00 urn:sha1:c5f087c6c031837a968277278b7d6de4ae1692fb 2015-04-11T16:16:15+00:00 deraadt 2015-04-11T16:16:15+00:00 urn: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 2015-02-22T16:03:06+00:00 jsing 2015-02-22T16:03:06+00:00 urn:sha1:bb820e160520888599d0966ac5d4a5270c855a23 Discussed with/requested by deraadt@ at the conclusion of s2k15. 2015-02-07T06:20:00+00:00 jsing 2015-02-07T06:20:00+00:00 urn:sha1:f890c33ffb541a5f8ab6f17b6b90c906bc74cacc Requested by deraadt@ 2015-01-22T09:06:39+00:00 reyk 2015-01-22T09:06:39+00:00 urn:sha1:862d0b8723d1dd780e301615518a21818f474a9c instead of disk. OpenSSL didn't provide a built-in API from loading certificates in a chroot'ed process that doesn't have direct access to the files. X509_STORE_load_mem() provides a new backend that will be used by libssl and libtls to implement such privsep-friendly functionality. Adopted for LibreSSL based on older code from relayd (by pyr@ and myself) With feedback and OK bluhm@ 2014-11-17T20:31:22+00:00 miod 2014-11-17T20:31:22+00:00 urn:sha1:1327462df8cb4ae2dc056e0de53b4b4dc50f50fa 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.