Discussion:
[strongSwan-dev] Building strongSwan for Windows on Linux
Kevin Lussier
2017-08-22 23:37:31 UTC
Permalink
Hello all.

I am trying to cross-compile strongSwan for Windows using MinGW64 on Ubuntu 16.04 (64-bit). The problem I am having at the moment is OpenSSL.

My steps were:

Install MinGW64
sudo apt-get install mingw-w64

Build OpenSSL
git clone https://github.com/openssl/openssl.git OpenSSL_1_1_0-stable
cd OpenSSL_1_1_0-stable
git checkout OpenSSL_1_1_0-stable
./Configure --prefix=$PWD/build --cross-compile-prefix=x86_64-w64-mingw32- mingw64 no-asm no-deprecated mingw64
make
make install

Grab strongSwan 5.6.0
git clone git://git.strongswan.org/strongswan.git
cd strongswan
git checkout 5.6.0

Now, at this point I hit a problem. If I just run autogen.sh, it would produce a configure file that has 'openssl_lib=eay32', but OpenSSL no longer builds libraries with that name. So I changed that line to be 'openssl_lib=crypto'.

Issue the configure command
./autogen.sh
./configure --prefix=$PWD/build --disable-defaults --enable-monolithic --enable-static --enable-svc \
--enable-ikev2 --enable-ikev1 --enable-nonce --enable-pem --enable-pkcs1 --enable-x509 \
--enable-openssl --enable-socket-win --enable-kernel-wfp --enable-kernel-iph --enable-pubkey \
--enable-swanctl --with-swanctldir=swanctl --with-strongswan-conf=strongswan.conf --host=x86_64-w64-mingw32 \
CFLAGS="-g -O2 -Wall -Wno-pointer-sign -Wno-format-security -Wno-format -mno-ms-bitfields -I/home/kevin/OpenSSL_1_1_0-stable/build/include" \
LDFLAGS="-L/home/kevin/OpenSSL_1_1_0-stable/build/lib"

The configure works, but there is one item of note in the output:
checking for EVP_CIPHER_CTX_new in -lcrypto... yes
checking openssl/evp.h usability... yes
checking openssl/evp.h presence... no
configure: WARNING: openssl/evp.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: openssl/evp.h: proceeding with the compiler's result
checking for openssl/evp.h... yes

Run the make
make

This is my point of failure. The build fails when compiling the openssl plugin:

Making all in plugins/openssl
make[5]: Entering directory `/home/kevin/strongswan-5.6.0/src/libstrongswan/plugins/openssl'
depbase=`echo openssl_rsa_private_key.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../../../../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/libstrongswan -DFIPS_MODE=0 -I/usr/local/include -g -O2 -Wall -Wno-pointer-sign -Wno-format-security -Wno-format -mno-ms-bitfields -I/home/kevin/openssl-master/build/include -include /home/kevin/strongswan-5.6.0/config.h -MT openssl_rsa_private_key.lo -MD -MP -MF $depbase.Tpo -c -o openssl_rsa_private_key.lo openssl_rsa_private_key.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/libstrongswan -DFIPS_MODE=0 -I/usr/local/include -g -O2 -Wall -Wno-pointer-sign -Wno-format-security -Wno-format -mno-ms-bitfields -I/home/kevin/openssl-master/build/include -include /home/kevin/strongswan-5.6.0/config.h -MT openssl_rsa_private_key.lo -MD -MP -MF .deps/openssl_rsa_private_key.Tpo -c openssl_rsa_private_key.c -DDLL_EXPORT -DPIC -o .libs/openssl_rsa_private_key.o
In file included from /usr/share/mingw-w64/include/windows.h:95:0,
from /usr/share/mingw-w64/include/winsock2.h:23,
from ../../../../src/libstrongswan/utils/compat/windows.h:24,
from ../../../../src/libstrongswan/utils/utils.h:38,
from ../../../../src/libstrongswan/library.h:101,
from ../../../../src/libstrongswan/credentials/builder.h:41,
from openssl_rsa_private_key.h:26,
from openssl_rsa_private_key.c:25:
/home/kevin/openssl-master/build/include/openssl/x509.h:84:34: error: expected ')' before numeric constant
typedef STACK_OF(X509_EXTENSION) X509_EXTENSIONS;
^


I originally tried using a pre-built OpenSSL from https://slproweb.com/products/Win32OpenSSL.html, but the strongSwan build failed the same way. That's why I built OpenSSL myself, hoping it would fix the problem. However, since it appears to be a problem with the headers, it's not too surprising that both builds failed.

So, can anyone tell me what I am doing wrong?

Thanks,
Kevin
Tobias Brunner
2017-08-23 07:47:38 UTC
Permalink
Hi Kevin,
Post by Kevin Lussier
In file included from /usr/share/mingw-w64/include/windows.h:95:0,
from /usr/share/mingw-w64/include/winsock2.h:23,
from
../../../../src/libstrongswan/utils/compat/windows.h:24,
from ../../../../src/libstrongswan/utils/utils.h:38,
from ../../../../src/libstrongswan/library.h:101,
from
../../../../src/libstrongswan/credentials/builder.h:41,
from openssl_rsa_private_key.h:26,
expected ')' before numeric constant
typedef STACK_OF(X509_EXTENSION) X509_EXTENSIONS;
^
That output looks a bit odd (as if windows.h included x509.h, check if
that's actually the case). But windows.h does include wincrypt.h, if
NOCRYPT is not defined, which has a conflicting definition for
X509_EXTENSIONS (see [1]). You could try to add -DNOCRYPT to your CFLAGS.

Interesting that this issue doesn't occur in our AppVeyor build [2].
However, we do link against libeay32 there and not libcrypto, so there
might be some compatibility fixes applied - not sure why this is
different in your build (what's the result of the "checking for Windows
target" configure check? check config.log for details).

Regards,
Tobias

[1]
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/wincrypt.h
[2] https://ci.appveyor.com/project/tobiasbrunner/strongswan-52lo9
Kevin Lussier
2017-08-23 21:21:38 UTC
Permalink
Hi Tobias.

Thanks for your response. Using your suggestion I was finally able to get it building. However, there were a couple of caveats along the way.

First, in my OpenSSL build I had set the ‘no-deprecated’ flag during configure, but apparently strongSwan is still using some deprecated functions. Once I rebuilt openSSL that got rid of most of the warnings during the build. However, that’s when I hit the second problem.

Since NOCRYPT is now specified as one of my CFLAGS, when it came time to build kernel_iph_net.c, it failed because apparently the crypto API is needed for that to compile. So I added

#ifdef NOCRYPT
#undef NOCRYPT
#endif

to the top of that file. After that change the build was able to complete and I can successfully run charon-svc.exe.

But I’m still confused as to why I am seeing this problem when apparently no one else is. Could it simply be that no one else has built Windows strongSwan with the latest openSSL? That seems unlikely, though I guess possible.

Also, I’m new to open source development so I’m not sure what the procedure here is, but I’d like to get the changes I’ve made to configure.ac and kernel_iph_net.c back into the main repository so other people don’t have the same issue. I guess that assumes that the changes I’ve made are correct, which other people may or may not agree with :-)

Thanks,
Kevin
Post by Tobias Brunner
Hi Kevin,
Post by Kevin Lussier
In file included from /usr/share/mingw-w64/include/windows.h:95:0,
from /usr/share/mingw-w64/include/winsock2.h:23,
from
../../../../src/libstrongswan/utils/compat/windows.h:24,
from ../../../../src/libstrongswan/utils/utils.h:38,
from ../../../../src/libstrongswan/library.h:101,
from
../../../../src/libstrongswan/credentials/builder.h:41,
from openssl_rsa_private_key.h:26,
expected ')' before numeric constant
typedef STACK_OF(X509_EXTENSION) X509_EXTENSIONS;
^
That output looks a bit odd (as if windows.h included x509.h, check if
that's actually the case). But windows.h does include wincrypt.h, if
NOCRYPT is not defined, which has a conflicting definition for
X509_EXTENSIONS (see [1]). You could try to add -DNOCRYPT to your CFLAGS.
Interesting that this issue doesn't occur in our AppVeyor build [2].
However, we do link against libeay32 there and not libcrypto, so there
might be some compatibility fixes applied - not sure why this is
different in your build (what's the result of the "checking for Windows
target" configure check? check config.log for details).
Regards,
Tobias
[1]
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/wincrypt.h
[2] https://ci.ap
Tobias Brunner
2017-08-24 08:34:48 UTC
Permalink
Hi Kevin,
Post by Kevin Lussier
First, in my OpenSSL build I had set the ‘no-deprecated’ flag during configure, but apparently strongSwan is still using some deprecated functions.
The plugin tries to work with pretty much any version of OpenSSL (and
BoringSSL, not so much LibreSSL at the moment). But these *SSL
libraries have been a real crapfest in regards to API changes in recent
years leading to lots of ifdefs and small wrapper macros. Could very
well be that there are some still missing for OpenSSL 1.1 (I guess the
distro versions of it are not compiled with no-deprecated, so somebody
needs to do some compatibly checks against different API versions).
Post by Kevin Lussier
But I’m still confused as to why I am seeing this problem when apparently no one else is.
As I mentioned before, the Windows detection in the configure script
does not seem to work correctly on your system (otherwise there would be
an attempt to link libeay32 and not libcrypto - unless you changed that
in the script). This could mean that e.g. _WIN32 is also not defined.
Because if it was OpenSSL's ossl_typ.h header, included in x509.h, for
instance, would undefine the conflicting defines.
Post by Kevin Lussier
Could it simply be that no one else has built Windows strongSwan with the latest openSSL? That seems unlikely, though I guess possible.
That's actually entirely possible as there are probably not that many
people building strongSwan for Windows.

Regards,
Tobias
Kevin Lussier
2017-08-24 16:46:52 UTC
Permalink
Hi Tobias.

That all makes sense. And you’re right, I had modified configure.ac to use crypto instead of eay32 and forgot to mention that in my original post. This was necessary since OpenSSL now outputs libcrypto and not libeay32 on Windows builds.

I think ideally the configure script would be updated to check for both versions (crypto first and then eay32) if older versions of OpenSSL are going to still be supported.

Kevin
Post by Tobias Brunner
Hi Kevin,
Post by Kevin Lussier
First, in my OpenSSL build I had set the ‘no-deprecated’ flag during configure, but apparently strongSwan is still using some deprecated functions.
The plugin tries to work with pretty much any version of OpenSSL (and
BoringSSL, not so much LibreSSL at the moment). But these *SSL
libraries have been a real crapfest in regards to API changes in recent
years leading to lots of ifdefs and small wrapper macros. Could very
well be that there are some still missing for OpenSSL 1.1 (I guess the
distro versions of it are not compiled with no-deprecated, so somebody
needs to do some compatibly checks against different API versions).
Post by Kevin Lussier
But I’m still confused as to why I am seeing this problem when apparently no one else is.
As I mentioned before, the Windows detection in the configure script
does not seem to work correctly on your system (otherwise there would be
an attempt to link libeay32 and not libcrypto - unless you changed that
in the script). This could mean that e.g. _WIN32 is also not defined.
Because if it was OpenSSL's ossl_typ.h header, included in x509.h, for
instance, would undefine the conflicting defines.
Post by Kevin Lussier
Could it simply be that no one else has built Windows strongSwan with the latest openSSL? That seems unlikely, though I guess possible.
That's actually entirely possible as there are probably not that many
people building strongSwan for Win
Tobias Brunner
2017-08-30 13:08:42 UTC
Permalink
Hi Kevin,
Post by Kevin Lussier
I think ideally the configure script would be updated to check for both versions (crypto first and then eay32) if older versions of OpenSSL are going to still be supported.
I've changed the check in the windows-openssl-1.1 branch. However, I
first check for libeay32 because otherwise the build may be linked
against the build environment's version (usually called libcrypto) and
not the native build when using older OpenSSL versions.

Regards,
Tobias

Loading...