A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_5_9_BASE 2016-02-17T13:06:55+00:00 2016-02-17T13:06:55+00:00 cvs2svn admin@example.com 2016-02-17T13:06:55+00:00 urn:sha1:c192600fadb763f0d8645c69f309093e3709f18c 2015-09-11T14:48:06+00:00 miod 2015-09-11T14:48:06+00:00 urn:sha1:9750a3821f26639c541ea7c893d977024d363b62 machinery. OpenBSD has never been not ELF on amd64, and changing this will actually make -portable life slightly easier in the near future. 2015-06-19T06:05:11+00:00 bcook 2015-06-19T06:05:11+00:00 urn:sha1:1ef7c35782edea8e65610a2d9d6d6d08ea90983c We do not build, test or ship any dynamic engines, so we can remove the dynamic engine loader as well. This leaves a stub initialization function in its place. ok beck@, reyk@, miod@ 2015-03-18T05:26:10+00:00 miod 2015-03-18T05:26:10+00:00 urn: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. 2015-03-05T20:35:28+00:00 miod 2015-03-05T20:35:28+00:00 urn: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@ 2014-12-07T15:45:44+00:00 miod 2014-12-07T15:45:44+00:00 urn:sha1:b337353782d8665f6364fa0d468370c06ac96423 bn_div_words, bn_mul_add_words, bn_mul_words, bn_sqr_words, bn_sub_words) on sgi, because the generated assembly code isn't R4000-safe. 2014-11-22T07:17:50+00:00 deraadt 2014-11-22T07:17:50+00:00 urn:sha1:fbe61763de8269e9c714ab6c2d66e0e3eea2c18a 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-09-27T20:42:38+00:00 miod 2014-09-27T20:42:38+00:00 urn:sha1:ca6cdf7e807ad940eb851dfee98ddff6e4052816 fixed. 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.