openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <>
Subject Re: svn commit: r1756954 [1/2] - in /openoffice/trunk/main: ./ openssl/
Date Fri, 19 Aug 2016 20:30:02 GMT
On 19 Aug, To: wrote:
> On 19 Aug, Dennis E. Hamilton wrote:
>> Great commit messages!
>>> -----Original Message-----
>>> From: []
>>> Sent: Friday, August 19, 2016 11:28
>>> To:
>>> 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:
>>> 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,
>>> <>.  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:
For additional commands, e-mail:

View raw message