configure.ac: fix building against static openssl
PATCH 1/1 configure.ac: fix building against static openssl
Instead of searching for both libssl and libcrypto, just search for openssl as a whole (which depends on libssl and libcrypto). The previous discovery order would result in "-lcrypto -lssl" link flags, while we need "-lssl -lcrypto".
Trac: #863
---
This patch is for release/2.4 only, because this is already fixed in master by commit 79ea67f77ca3afe91222f62e17df885a30409285.
configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
configure.ac +1 -1
@@ -859,7 +859,7 @@ if test "${enable_crypto}" = "yes" -a "${with_crypto_library}" = "openssl"; then # if the user did not explicitly specify flags, try to autodetect PKG_CHECK_MODULES( [OPENSSL], - [libcrypto >= 0.9.8, libssl >= 0.9.8], + [openssl >= 0.9.8], [have_openssl="yes"], [have_openssl="no"] # Provide if-not-found to prevent erroring out )
Signature · 1 line
2.7.4
Quoted 21 lines · Steffan Karger
Instead of searching for both libssl and libcrypto, just search for openssl as a whole (which depends on libssl and libcrypto). The previous discovery order would result in "-lcrypto -lssl" link flags, while we need "-lssl -lcrypto".
Trac: #863
Signed-off-by Steffan Karger <[email protected]...>---
This patch is for release/2.4 only, because this is already fixed in master by commit79ea67f77ca3afe91222f62e17df885a30409285.configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)configure.ac +0
-0
configure.ac if test "${enable_crypto}" = "yes" -a "${with_crypto_library}" = "openssl"; then · line 865
Quoted 8 lines
configure.ac +1
-1@@ -859,7 +859,7 @@ if test "${enable_crypto}" = "yes" -a "${with_crypto_library}" = "openssl"; then # if the user did not explicitly specify flags, try to autodetect PKG_CHECK_MODULES( [OPENSSL], - [libcrypto >= 0.9.8, libssl >= 0.9.8], + [openssl >= 0.9.8], [have_openssl="yes"], [have_openssl="no"] # Provide if-not-found to prevent erroring out )
I vaguely remember we discussed the OpenSSL versions. On the Linux side, we shouldn't need to worry about anything older than 1.0.1.
I do however vaguely remember someone mentioning some BSD distros still being on 0.9.8 ... or was it some other OS? ... Anyhow, do we need to care for them? This is release/2.4 we're talking about after all.
If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Am 31.05.2017 um 02:31 schrieb David Sommerseth:
Quoted 4 lines
I do however vaguely remember someone mentioning some BSD distros still being on 0.9.8 ... or was it some other OS? ... Anyhow, do we need to care for them? This is release/2.4 we're talking about after all.
The oldest OpenSSL version in use a supported FreeBSD version is FreeBSD 10.3's OpenSSL 1.0.1.
I haven't looked at other BSDs.
Hi,
Quoted 3 lines · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.
You are the one that objects most violently if we break users' expectations
- and I think "changing library *requirements* right in the middle of a release train" is a good way to do that... even if all *supported by the maintainers* OS version have recent-enough OpenSSL libraries, I expect people to happily use 2.4.2 on "something", and if 2.4.3 stops compiling there, this is not a good thing to do.
So I'd just fix the library order (= go with Steffan's patch) and not backport the larger changes.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Quoted 8 lines · Gert Doering
Hi,
Quoted 3 lines · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.You are the one that objects most violently if we break users' expectations
Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.
And when we have had the policy (at least on the Linux side) that the oldest supported library and build dependencies are what the oldest officially supported RHEL release carries, then moving to OpenSSL 1.0.1 should not break anything.
When also considering that any releases older than OpenSSL 1.0.2 is not supported by OpenSSL upstream [1], and OpenSSL 1.0.1 is supported by at least Red Hat in RHEL for the lifetime of RHEL ... Then ditching 0.9.8 support makes even more sense.
[1] <https://www.openssl.org/policies/releasestrat.html>
If there are other OS/distros actively supporting, fixing and backporting security fixes to 0.9.8, then I have no issues keeping 0.9.8 support. But unless there are someone having this requirement, cleaning up all the various OpenSSL hacks for unsupported version is fairly sensible to me.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Hi,
Quoted 8 lines · David Sommerseth
Quoted 7 lines · Gert Doering
Hi,
Quoted 3 lines · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.
Quoted 5 lines
Quoted 1 line
You are the one that objects most violently if we break users' expectations
Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.
Well, this is a somewhat simplistic world view, with "package builders" and "package installers".
People are stuck on older enterprise distributions, for whatever reasons, but want a newer openvpn version - so they get the source bundle, and compile. Which is a perfectly fine deployment model - and we should not break things in 2.4.3 that worked just fine in 2.4.2 for them (unless there is a strong reason, like "we have a vulnerability here that we cannot fix unless we abandon an older API").
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Quoted 23 lines
Hi,
Quoted 9 lines · David Sommerseth
Quoted 4 lines · Gert Doering
Hi,
Quoted 1 line · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can
give
Quoted 3 lines
Quoted 2 lines
this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.Quoted 7 lines
Quoted 1 line
You are the one that objects most violently if we break users'
expectations
Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.
Well, this is a somewhat simplistic world view, with "package builders" and "package installers".
Quoted 6 lines
People are stuck on older enterprise distributions, for whatever reasons, but want a newer openvpn version - so they get the source bundle, and compile. Which is a perfectly fine deployment model - and we should not break things in 2.4.3 that worked just fine in 2.4.2 for them (unless there is a strong reason, like "we have a vulnerability here that we cannot fix unless we abandon an older API").
I strongly support your view, Gert. I really hope we do not see such breakage in minor stable releases.
Regards,
Simon
Quoted 30 lines · Simon Matter
Quoted 23 lines
Hi,
Quoted 9 lines · David Sommerseth
Quoted 4 lines · Gert Doering
Hi,
Quoted 1 line · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can
give
Quoted 3 lines
Quoted 2 lines
this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.Quoted 7 lines
Quoted 1 line
You are the one that objects most violently if we break users'
expectations
Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.
Well, this is a somewhat simplistic world view, with "package builders" and "package installers".
Quoted 6 lines
People are stuck on older enterprise distributions, for whatever reasons, but want a newer openvpn version - so they get the source bundle, and compile. Which is a perfectly fine deployment model - and we should not break things in 2.4.3 that worked just fine in 2.4.2 for them (unless there is a strong reason, like "we have a vulnerability here that we cannot fix unless we abandon an older API").
Quoted 2 lines
I strongly support your view, Gert. I really hope we do not see such breakage in minor stable releases.
Do you depend on building against OpenSSL 0.9.8? If so, which OS/distribution do you use?
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Quoted 34 lines · Simon Matter
Quoted 33 lines
Quoted 32 lines
Hi,
Quoted 9 lines · David Sommerseth
Quoted 4 lines · Gert Doering
Hi,
Quoted 1 line · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can
give
Quoted 3 lines
Quoted 2 lines
this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.Quoted 8 lines
Quoted 1 line
You are the one that objects most violently if we break users'
expectations
Yes and no. In regards to end users, I am very careful. In regards to
package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.Well, this is a somewhat simplistic world view, with "package builders" and "package installers".
People are stuck on older enterprise distributions, for whatever reasons,
but want a newer openvpn version - so they get the source bundle, and compile. Which is a perfectly fine deployment model - and we should not
break things in 2.4.3 that worked just fine in 2.4.2 for them (unless there is a strong reason, like "we have a vulnerability here that we cannot fix unless we abandon an older API").
Quoted 5 lines
Quoted 2 lines
I strongly support your view, Gert. I really hope we do not see such breakage in minor stable releases.
Do you depend on building against OpenSSL 0.9.8? If so, which OS/distribution do you use?
Yes, I have a case with very customized CentOS 5 systems where we also backport security related patches. Of course the same could be done for openvpn but it's easier to just follow the current 2.4 stream. That's why my suggestion to keep all the compat hacks in 2.4.x and kick them out only in the main devel branch. I guess that's what most package maintainers expect to happen and it keep mailing lists quiet.
Regards,
Simon
On 31/05/17 17:48, Simon Matter wrote:
[...snip...]
Quoted 6 lines
Quoted 3 lines
Do you depend on building against OpenSSL 0.9.8? If so, which OS/distribution do you use?
Yes, I have a case with very customized CentOS 5 systems where we also backport security related patches.
Well, officially we no longer support RHEL 5 or older as of v2.4. AFAIR, we even agreed late last year when getting ready for the 2.4 release that we won't intentionally break 2.4 builds on unsupported distros but we will not bother supporting it when we want to move forward.
It is good you take care of backporting security related patches. But wanting the OpenVPN community to maintain new OpenVPN releases buildable on those old distros is effectively shifting that responsibility over to the OpenVPN community.
Had the v2.5 release been in the pipe for the next 6-7 months or so, then I would be more easily persuaded to let v2.4 keep support for
openssl-0.9.8 around. But the reality is that we don't currently have
a release plan for v2.5.
Quoted 2 lines
Of course the same could be done for openvpn but it's easier to just follow the current 2.4 stream.
Right, having others doing your work is always the easiest path for yourself ;-)
Quoted 2 lines
That's why my suggestion to keep all the compat hacks in 2.4.x and kick them out only in the main devel branch.
Which is really speaking against what was the agreement when the 2.4 release started to take shape late last year.
But AFAIR, there also exists compat-openssl10 in RHEL5. Which could resolve this issue for you.
Quoted 2 lines
I guess that's what most package maintainers expect to happen and it keep mailing lists quiet
Most package maintainers wants to have as little work as possible while providing the latest and greatest to their users. But how that is achieved is primarily the package maintainer's responsibility.
We as a the upstream project will strive to make life as easy as possible for package maintainers, but not at any cost.
I further encourage you to read chapter 6.9 in the Quarklabs security audit [1]. Their recommendation is:
"We thus recommend suppressing these workarounds and to return an
error during compile time if the OpenSSL version is too old. Only versions 1.0.2 and further should be satisfactory."
Also have in mind that this audit is performed against the v2.4 code base.
So when we're having 1.0.1e as the oldest supported OpenSSL version (as that is what RHEL6 and RHEL7 ships and gets security fixes), I think that enforcing v2.4 to comply to this strengthens the overall security in OpenVPN.
If package maintainers want to run OpenVPN v2.4 on older OS/distro releases with older OpenSSL libraries, then that is their own decision and they need to take care of the additional work themselves. Insisting on upstream OpenVPN developers to make package maintainer's life easy and disregarding recommendations from security auditors at the same time is at best a fairly ignorant attitude.
And in practicality, package maintainers will then need to revert the two commits which removes support for older OpenSSL versions.
[1] <https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf>
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Quoted 11 lines · David Sommerseth
On 31/05/17 17:48, Simon Matter wrote:
[...snip...]Quoted 4 lines
Quoted 2 lines
Do you depend on building against OpenSSL 0.9.8? If so, which OS/distribution do you use?
Yes, I have a case with very customized CentOS 5 systems where we also backport security related patches.
Well, officially we no longer support RHEL 5 or older as of v2.4. AFAIR, we even agreed late last year when getting ready for the 2.4 release that we won't intentionally break 2.4 builds on unsupported distros but we will not bother supporting it when we want to move forward.
Just found some old IRC discussions from my archives.
It all starts back in February 9, 2016 where it was discussed what to do in regards to support AEAD. That is only supported in openssl-1.0.0 and newer.
[11:21:23] <syzzer> aead need polar 1.3+ or openssl 1.0.0+ (from the top of my head) [11:21:42] <syzzer> but since we have to support openssl 0.9.8 (RHEL5...), we need the #ifdefs [11:22:01] <syzzer> I made it use-configureable just because OFB/CFB is too [12:25:43] <plaisthos> syzzer: do we support RHEL5 in 2.4?
[12:27:17] <plaisthos> in 2.3 sure, but in 2.4?
[12:27:40] <plaisthos> dazo: any strong objections to drop RHEL5 support in 2.4? [12:28:31] <plaisthos> 5.0 came out in 2007 and the last update (5.11) was in 2014 [12:28:38] <plaisthos> (still supported but still)
[12:30:24] <syzzer> plaisthos: dazo did argue for supporting RHEL5 a number of times [12:31:19] <plaisthos> syzzer: :(
[13:39:48] <mattock> what does "support RHEL5 mean in this context"?
[13:40:23] <mattock> afaik packages in RHEL5 have (security) patches backported anyways [13:40:52] <cron2> mattock: prehistoric OpenSSL, so "#ifdef in the AEAD code" [13:41:04] <mattock> do we need to care about that?
[13:41:24] <cron2> well, I do care about the #ifdef, and dazo cares about RHEL5... [13:41:31] <cron2> so, sort of stalemate :)
(cron2 = Gert, syzzer = Steffan, plaisthos = Arne, mattock == Samuli, dazo == me)
At that time, the release plan for 2.4 was non-existing, but we wanted it "soonish". And Gert was right, at that time I cared about RHEL5 support. But the time dragged with no eminent v2.4 release ahead.
In September 5, 2016 this came up again, this time in regards to how to handle OpenSSL 1.1 support.
[14:27:17] <syzzer> I have an experimental branch with openssl 1.1 support, but that requires a *lot* of changes
[14:27:52] <syzzer> and it will be quite hard/ugly to support both 0.x/1.0.x and 1.1.x :(
[14:29:01] <syzzer> they made a lot structs opaque, and require you to use accessors that are not available in 0.x/1.0.x...
[14:33:38] <plaisthos> so basically they did not give you the new apis in 1.0.x to make life easy
[14:33:54] <plaisthos> are the new accessor just wrappers?
[14:34:04] <plaisthos> so we can do a compat_openssl_1.0.x.c?
[14:34:23] <syzzer> so yes, we have to add our own wrappers
[16:09:23] <dazo> plaisthos: iirc, it is only the z-version which keeps the API ... x.y versions updates API
[16:09:28] <dazo> (openssl that is)
[16:11:25] <dazo> Regarding compatibility ... for 2.4, we will need to support 0.9.8 (RHEL5) ... unless we postpone 2.4 until EOL of RHEL5 .... for RHEL6 we can move to 1.0.1 [16:11:37] <dazo> syzzer: plaisthos: ^^^
[16:12:18] <dazo> openssl-1.0.1e-48 (RHEL6) openssl-1.0.1e-51 (RHEL7)
[16:15:36] <plaisthos> ut RHEL5 is only on extended support right?
[16:25:27] <dazo> It has full support until end of March next year, IRC ... after that it is extended support for 2-3 years (which we do not support) [16:25:41] <dazo> (or extended support can stay on last supported version)
[16:25:57] <syzzer> well, as long as we support 2.3 until March, we're fine, right?
[16:26:02] <dazo> right
[16:26:34] <dazo> or 2.4 if that gets out the door in too too far future
[16:34:06] <syzzer> I mean, we can drop 0.9.8-support in master, if we pledge to support 2.3 until RHEL5 goes EOL
[16:35:01] * syzzer likes to reduce the maintenance burden
And in October 11, 2016 the v2.4 release plan began to become more realistic. And here I have shifted my opinion in regards to RHEL5 support in v2.4. That discussion started of due to some NetBSD patches.
[12:43:31] <cron2> dazo: crossing the streams :) - that was about tun-ipv6 and NETBSD_MULTI_AF
[12:44:28] <dazo> for the NetBSD ... I'd say get rid of the #ifdef if not really needed ... 9 year old NetBSD release is not something I'd expect to see around
[12:45:32] <cron2> what I said :)
[12:45:48] <dazo> :)
[12:49:40] <plaisthos> okay like the 8 year old linux stuff :0
[12:50:01] <plaisthos> (8 year ago added, so older than 8 year probably)
[12:55:34] <dazo> plaisthos: kind of, even though we need to be somewhat careful in regards to Enterprise Linux, which have official 10 years+ support - I don't think such long lasting commercial support exists for NetBSD, so it goes into the same category as the other non-Enterprise Linux distros ... does that make sense? [12:59:11] <plaisthos> dazo: yes
[13:05:47] <dazo> I don't really care for stuff older than RHEL5, tbh ... and I wouldn't even complain if we're moving towards RHEL6 as the oldest release for git master (RHEL5 have the EOL in 6 months)
[13:06:11] <cron2> RHEL5 can fall into the same bucket as NetBSD 4.x - "it is supported in 2.3.x"
Now, in hindsight it is very easy to see at we have done a very poorly job in regards to communicate out these expectations. This is something we should document far better, so the expectations are set as early as possible.
This was also mentioned in a discussion on the -devel mailing list in February 2017, this time when reviewing OpenSSL 1.1 support patches:
<https://www.mail-archive.com/[email protected]/msg14069.html>
Stefan did mention that SUSE Enterprise Linux 11 still ships with OpenSSL 0.9.8 by default, but that release also had support for OpenSSL 1.0.x.. So even that distribution is moving forward.
<https://www.mail-archive.com/[email protected]/msg14742.html>
I hope you see that the support for old OpenSSL versions have been discussed, directly and indirectly over a longer period of time and that RHEL5 only have our v2.3 support and not v2.4. With this in mind we should not feel committed to carry support for OS/distributions not targeted in v2.4.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Quoted 22 lines · David Sommerseth
Quoted 6 lines · Gert Doering
Quoted 3 lines · David Sommerseth
If we really do care for supporting 0.9.8, in release/2.4 - I can give this an ACK. Otherwise, I think it might be better to backport
039a89c331e9b7998d804+79ea67f77ca3afe91222f.You are the one that objects most violently if we break users' expectations
Yes and no. In regards to end users, I am very careful. In regards to package maintainers, I am less weary as they won't distribute failing builds to end users. This change hits package building, not the end user.
And when we have had the policy (at least on the Linux side) that the oldest supported library and build dependencies are what the oldest officially supported RHEL release carries, then moving to OpenSSL 1.0.1 should not break anything.
When also considering that any releases older than OpenSSL 1.0.2 is not supported by OpenSSL upstream [1], and OpenSSL 1.0.1 is supported by at least Red Hat in RHEL for the lifetime of RHEL ... Then ditching 0.9.8 support makes even more sense.
Quoted 7 lines
[1] <https://www.openssl.org/policies/releasestrat.html>
If there are other OS/distros actively supporting, fixing and backporting security fixes to 0.9.8, then I have no issues keeping 0.9.8 support. But unless there are someone having this requirement, cleaning up all the various OpenSSL hacks for unsupported version is fairly sensible to me.
Either backporting 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f or applying this patch is fine by me. As I wrote a little while ago:
Quoted 6 lines · Steffan Karger
The other big long-term-support distro, SLES, does still ship and support 0.9.8 in SELS11 until 2019 (2022 for extended support), but can be updated to 1.0.1.
As far as I'm concerned, that is enough reason to only support OpenSSL 1.0.1+ for OpenVPN 2.4 (and newer).
I'll let you guys decide.
-Steffan