A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v2.2.9 2015-07-19T22:34:27+00:00 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. 2014-11-09T19:12:18+00:00 miod 2014-11-09T19:12:18+00:00 urn:sha1:d92e6fdf5aae7a320effa3de769ce4c0378485c4 This functionality was already available (and optional), and used in the bowels of the ASN.1 code. This exposes it as a public interface, which will be used by the upcoming GOST code. Crank libcrypto minor version. From Dmitry Eremin-Solenikov. 2014-09-27T12:29:31+00:00 miod 2014-09-27T12:29:31+00:00 urn:sha1:4abc2ca359de7361381ad3dbc7845ad4c6d10172 cases and breaks TLS 1.2; crank libcrypto.so minor version out of safety and to be able to tell broken versions apart easily.