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 same result. And > for that trivial application they do! So why this difference breaks > authentication for me when it is all thrown together makes no sense. > > In my patch set you can see that I also changed what compiler switches > are used for the WinCE target. That change did not appear to fix or > break anything. > > I presume you are building for the ARM architecture since you didn't specify. Have you checked if reverting to the old compiler switches makes 1.0.1k work properly (even though it didn't break 1.0.1j)? The entire thing looks like a compiler bug in handling the expression used in 1.0.1k? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
