On 19 Aug, To: dev@openoffice.apache.org wrote: > On 19 Aug, Dennis E. Hamilton wrote: >> Great commit messages! >> >>> -----Original Message----- >>> From: truck...@apache.org [mailto:truck...@apache.org] >>> Sent: Friday, August 19, 2016 11:28 >>> To: comm...@openoffice.apache.org >>> Subject: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./ >>> openssl/ >>> >>> Author: truckman >>> Date: Fri Aug 19 18:28:06 2016 >>> New Revision: 1756954 >>> >>> URL: http://svn.apache.org/viewvc?rev=1756954&view=rev >>> Log: >>> Update the bundled version of OpenSSL from 0.9.8zh to 1.0.2h which >>> fixes many vulnerabiliies and adds support for newer, more secure >>> ciphers and versions of the protocol. >>> >>> Note: OpenSSL version 1.0.2h contains two known minor vulnerabilites, >>> CVE-2016-2177 and CVE-2016-2178, which will be fixed in the next >>> OpenSSL release. Their potential impact is low enough that that >>> various Linux distros have chosen not to apply the upstream patches >>> to the versions that they distribute. >>> >>> On Windows, there is an optional new dependency on NASM, >>> <http://www.nasm.us/>. If NASM is not available, then the C >>> implementations of the low-level crypto code will be used instead >>> of the optimized assembly language versions. Since OpenOffice is >>> not a heavy user of this code, the impact should be minor. If NASM >>> is installed, but its location is not in $PATH, the directory >>> containing nasm.exe should be passed to configure using --with-nasm- >>> home. >>> >> [ ... ] >> [orcmid] >> >> Does the NASM code do the right thing with regard to CPU model >> detection? It sounds like there may be dependencies on instructions >> that may not be on all processors for which Apache OpenOffice is >> supported. I am thinking in particular about processors on which >> Windows XP will run but Windows 7 and later will not because of >> hardware protection requirements and, I suspect, extended instruction >> sets. > > It is supposed to select the appropriate version of the code at runtime > based on the CPU feature bits that tell whether the machine supports the > newer SSE* and AVX instructions. I should be able to give this a try in > the next few days.
I'm pretty sure the old version of OpenSSL also had optimized assembly language code as well. What's interesting is that the VS 7 assembler wasn't choking on any of the newer instructions but on a couple of ordinary looking MOV instructions. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org