As of Oct 2013, the most up-to-date version of openvpn is 2.3.2 and for polarssl is 1.3.0. This combination of openvpn with the polarssl USE flag enabled results in a build failure at the "configure" stage . An adequate workaround is to use an older version of polarssl. Builds of openvpn-2.3.2 with older versions of polarssl (in particular, v. 1.2.7) seem to work fine. However, a caveat: there seems to be no easy way to downgrade to older versions of polarssl, as the only ebuild available is for 1.3.0. Older ebuild versions have been dropped. Reproducible: Always Steps to Reproduce: 1. Emerge polarssl (current version 1.3.0) 2. Enable ssl and polarssl USE flags 3. Emerge openvpn (current version 2.3.2) Actual Results: See attachments for build.log Expected Results: Should not crash at "configure: error: ssl is required but missing" and be able to build smoothly using polarssl as the SSL library when the polarssl USE flag is enabled. Discussed briefly with pekster and kurly in #gentoo irc channel. It is a possible upstream bug. pekster mentioned he would contact openvpn about the issue. 23:12:42 pekster | kurly, mathadder, I'll file a bug with openvpn since I dug a bit earlier and I _think_ it's an openvpn issue (though not as easy as the version string thing I thought it was before. This is a more subtle bug :\ )
Created attachment 361586 [details] build.log
I thought this might be relevant. http://www.gentoo.org/security/en/glsa/glsa-201310-10.xml There are multiple vulnerabilities for polarssl version < 1.3.0. The workaround specified above yields a working build, but is vulnerable.
pekster has mentioned a good workaround to me in irc. Users can use polarssl version 1.2.10, as 1.2.9 seems to fix forementioned vulnerabilities and 1.2.10 fixes threading/memory leak issues in 1.2.9. https://polarssl.org/tech-updates/releases/polarssl-1.2.9-released https://polarssl.org/tech-updates/releases/polarssl-1.2.10-released
!!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-misc/openvpn-2.3.2/work/openvpn-2.3.2/config.log Where is it?
!!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-misc/openvpn-2.3.2/work/openvpn-2.3.2/config.log
This is an issue when zlib support is enabled in polarssl. It actually impacts the 1.2.x series as well, which can be confirmed by copying the 1.3.0 ebuild to a local overlay and naming it 1.2.10 (1.2.10 is still secure, so I'm not quite sure why all the 1.2 builds were removed from the portage tree. Different issue with that package maintenance though, so I won't discuss it further here.) When building polarssl with zlib (which un-comments `#define #POLARSSL_ZLIB_SUPPORT`) the following conftest.c fails to build during an openvpn ./configure. Note that this can be reproduced by running `./configure --with-crypto-library=polarssl` from openvpn sources (not even using portage -- demonstrating this is probably a polarssl bug, or possibly gentoo's build of it.) Consider this output, which I can get both with PolarSSL 1.2.10 and PolarSSL 1.3.0 when built with the option zlib support as described above: % cat conftest.c char ssl_init (); int main () { return ssl_init (); ; return 0; } % gcc -o conftest -lpolarssl conftest.c /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `inflate' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `deflate' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `deflateInit_' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `inflateEnd' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `deflateEnd' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libpolarssl.so: undefined reference to `inflateInit_' collect2: ld returned 1 exit status % gcc -o conftest -lpolarssl -lz conftest.c # <-- this one builds without error % ldd /usr/lib/libpolarssl.so # <-- note, missing libz reference, yet this polarssl was built with POLARSSL_ZLIB_SUPPORT linux-gate.so.1 (0xb77b0000) libc.so.6 => /lib/libc.so.6 (0xb75cb000) /lib/ld-linux.so.2 (0xb77b1000) The quick fix for now is to bump the openvpn ebuild revision to require polarssl not have zlib support if openvpn has the polarssl USE flag. Near as I can tell, the long-term fix needs to have libpolarssl.so linked against libz; it's obviously not openvpn's responsibility to "know that polarssl is compiled with libz but not linked properly."
Shifting ownership to Thomas, since it seems to be a polarssl bug.
Oh, and Josh, thanks for the thorough analysis! It might be also be swell if you could open up an upstream bug for polarssl to see what they say, and link to that from here.
I've been discussing this issue with an upstream developer, and this issue got even more complex. Upstream may break API compatibility between point-releases; this means an application written to use PolarSSL-1.2.x shouldn't be expected to work with PolarSSL-1.3.x. On top of this, the SOVERSION may be bumped for patch-releases too (such as from 1.3.0 to 1.3.1,) though I think this only applies to keeping the symlinks in sync (which means more hassle for maintainers as missing this breaks the symlink support.) At the very least, Gentoo will need to slot PolarSSL to the point-release level, because apps may well require a specific point-release. At this time, OpenVPN requires 1.2.x (of which only 1.2.10 is usable from upstream due to the current CVE on <1.2.9, and the memory leak with 1.2.9.) Additionally, the broken zlib support effectively requires use of cmake, not make, to do the build. My contact with upstream has indicated that if "non-defaults" are used, cmake is the correct build method, and the README in the PolarSSL sources seems to indicate that cmake is the preferred build method. What I plan to do now is open another bug against polarssl to both update the method to cmake and create package slots for the point-releaes. Once I do that, I'll mark that as a blocker for this issue. The result will be something like SLOT="1/2" for 1.2.x and SLOT="1/3" for 1.3.x; Gentoo's openvpn package can then depend on the necessary min/max version as required by the OpenVPN project, while other packages can still explicitly depend on a 1.3.x version with the slotted installation allowing both versions to co-exist.
Oh, and a quick note I forgot: there is indeed a bug (even with cmake) when enabling the not-upstream-default zlib support. That will be fixed upstream, and we can back-port the fix to the 1.2.10 version as well (which, in case it was clear above, will need to go back in the portage tree.) I'll reference the patch and (when available) upstream commit in the polarssl bug shortly.
we already use cmake in 1.3.4, but you will still get build failure see bug 501582
