Yes. The build methods were kept constant at first as I tried to upgrade.
Currently I am using STANDARDSDK_500 to build for CE50_ARMV4I, or at least that
is the build target that was tested. We also build for many other target
platforms as well, I haven't tested any of them yet. Details could probably be
provided if that is of any use. We use Ant/Ivy and Jenkins in our build
system. But most of the builds I performed locally without much of those
details involved. Batch files get launched that set up the details of the
build. Slight modifications have been made to the Perl scripts to enhance the
product. For example, the standard scripts avoid the use of resource files for
/CE/ builds. I not only use resource files, but improve the content of those
files to indicate our build version together with the OpenSSL version tag that
it is based upon. We also support FIPS so the resource file can indicate which
builds are FIPS compatible and which ones are not.
Ultimately I built all of the following versions:
* 1.0.1g -- legacy version that has been working for years
* 1.0.1t -- built without error, failed to authenticate any 802.1x protocol
such as PEAP with our WPA supplicant.
* 1.0.2h -- built without error even easier than 1.0.1t, failed to authenticate
any 802.1x protocol such as PEAP with our WPA supplicant.
* 1.0.1n -- failed the same as the others that failed
* 1.0.1i -- works the same as 1.0.1g
* 1.0.1l -- failed the same as the others that failed
* 1.0.1k -- failed to compile until I ported a one-line fix from a later
version, then built okay but failed to function correctly
* 1.0.1j -- works
* I tediously sliced up the differences between 1.0.1j and 1.0.1k to discover
first the file and then the minimum set of changes required to reproduce
failures.
* Have since then ported that conditional to our 1.0.2j build. It works and
that gets us to where we need to be right now. I realize that the conditional
I used may be overkill. But working is good enough for the company. Even it
if it not good enough for the open source community.
I further pursued the differences between working and not working, but haven't
been able to reproduce failure apart from a full OpenSSL build. In other
words, in a small test program both methods for computing constant_time_msb
worked fine. The assembly language is slightly different from one another
since the new method uses a logical shift operation whereas the previous method
uses an arithmetic shift operation, but never the less I was unable to
reproduce a compiler error using the same version of Microsoft compiler. I've
seen issues like this before where compiler errors depend upon more than just
the lines in question. Unfortunately I haven't the time to dedicate to
determining anything more about this issue since I have a working version that
meets our needs.
As indicated in the original email, the change to compiler switches neither
fixed nor broke anything. I only made that change after all of the tests
above, as an attempt to see if I could forgo changing source code altogether.
I prefer using the same optimization switches used for Win32 builds so I left
that change in even though it did not fix the compiler bug.
So ultimately this email is about reporting an issue that perhaps deserves
nothing more than a comment in source code, I don't know. I can keep an eye on
this issue and report any further developments as they are discovered. But it
will likely be a long time before we need to revisit work on OpenSSL.
-Ike-
John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Jakob Bohm
Sent: Monday, November 21, 2016 11:49 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since
OpenSSL version 1.0.1k
On 21/11/2016 19:52, Eichenberger, John wrote:
>
> I am building both OpenSSL and WPA Supplicant for use on a Windows
> Mobile 6.5 platform.
>
> The WPA Supplicant version in use is based upon the hostap_2_0 tag
> from http://w1.fi/hostap.git.
>
> The version of OpenSSL that we have been using until now is based upon
> the OpenSSL_1_0_1g from https://github.com/openssl/openssl
>
> I can upgrade to OpenSSL_1_0_1j and still succeed. But when I merge
> changes from OpenSSL_1_0_1k, all 802.1x authentication fails.
>
> I narrowed this problem down to a single line in
> crypto/constant_time_locl.h. Attached is the patch set that I applied
> to resolve this issue for me.
>
> It is a confusing issue because I can compile that same bit of code in
> Visual Studio within a different trivial application and see that
> although the two methods for that bit of code produce slightly
> different assembly language, both should produce the sam