Bug 238382 - security/openvpn: Fix build with libressl
Summary: security/openvpn: Fix build with libressl
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Matthias Andree
URL: https://sourceforge.net/p/openvpn/ope...
Depends on:
Reported: 2019-06-07 11:08 UTC by Luca Pizzamiglio
Modified: 2019-07-16 06:30 UTC (History)
1 user (show)

See Also:
mandree: maintainer-feedback+

The fixing patch (1.93 KB, patch)
2019-06-07 11:08 UTC, Luca Pizzamiglio
mandree: maintainer-approval-
Details | Diff
Patch from OpenBSD (1.77 KB, patch)
2019-06-11 12:07 UTC, Luca Pizzamiglio
no flags Details | Diff
set port to IGNORE when trying to build with libressl or libressl-devel (1.33 KB, patch)
2019-07-13 07:39 UTC, Matthias Andree
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Pizzamiglio freebsd_committer 2019-06-07 11:08:30 UTC
Created attachment 204874 [details]
The fixing patch

Building openvpn with libressl failed.
This is the patch to fix it.
Comment 1 Matthias Andree freebsd_committer 2019-06-07 18:22:47 UTC
Comment on attachment 204874 [details]
The fixing patch

Hi Luca, where's the patch from? Your own doing?

I'm loathe to take it because the upstream's Git repo at the master branch's commit a47508606be2c6359d4b27c3b65b72dfe4786222 has some comments that are rather discouraging for LibreSSL quality... "    - TLS 1.3 is not ready yet in LibreSSL. Also there is a theoretical possibility of OpenSSL >=1.1.1 built without TLS 1.3 support." - as of 2019-02-25, <https://sourceforge.net/p/openvpn/openvpn/ci/a47508606be2c6359d4b27c3b65b72dfe4786222/>

The release/2.4 branch that OpenVPN 2.4.7 was cut from doesn't have relevant code at all.

I'll have the upstream peek at your patch.

Reject for now, I may change my opinion if the upstream maintainers approve of it.
Comment 2 Matthias Andree freebsd_committer 2019-06-07 18:33:17 UTC
mailing list reference, https://sourceforge.net/p/openvpn/mailman/message/36688940/
Comment 3 Luca Pizzamiglio freebsd_committer 2019-06-11 09:45:09 UTC
I did it some time ago, so I've lost the origin of this patch.

I'm reworking it using https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-src_openvpn_ssl_openssl_c as source of truth
Comment 4 Luca Pizzamiglio freebsd_committer 2019-06-11 12:07:10 UTC
Created attachment 204987 [details]
Patch from OpenBSD

This patch (coming from OpenBSD https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-src_openvpn_ssl_openssl_c ) allows openvpn to build with libressl, disabling TLS 1.3
Comment 5 Matthias Andree freebsd_committer 2019-07-13 07:39:21 UTC
Created attachment 205745 [details]
set port to IGNORE when trying to build with libressl or libressl-devel


given that LibreSSL does not support TLS v1.3, LibreSSL has an awkward obtrusive API versioning that lives in its own universe while scribbling over OpenSSL compatibility (I've seen that myself while working on fetchmail [1]), and isn't popular among the upstream maintainers, I wonder if we shouldn't just declare OpenVPN incompatible with LibreSSL for now - see attached patch. What do you think? If I don't hear compelling arguments, I'll commit my patch instead.

I admit that the no-TLS1.3 is an argument that is 'dangerous' in that mbedTLS also currently lacks TLS 1.3, so by the same logic I would need to disable the mbedTLS port.

What also bothers me is that the OpenBSD patch adds quite a few #ifdefs that are extremely intransparent and inconsistent guesswork. One check checks compile-time features - !defined(OPENSSL_NO_TLS1_3) -, another checks presence of disabling options - defined(SSL_OP_NO_TLSv1_2) - and OPENSSL_VERSION_NUMBER checks are b0rked on LIBRESSL, and we'd have to re-review our patch of each and every LibreSSL version. (This doesn't apply to OpenBSD who are the upstream maintainers of LibreSSL.)

[1] https://gitlab.com/fetchmail/fetchmail/blob/124518ae5fba9e352a9cf8a8d7c1a8160475d10b/socket.c#L894
Comment 6 Matthias Andree freebsd_committer 2019-07-13 08:26:10 UTC
I think given the massive pushback given the current state of affairs, I won't add patches until LibreSSL fix their API versioning in a way that is acceptable by the OpenVPN team.
Comment 7 commit-hook freebsd_committer 2019-07-13 08:31:55 UTC
A commit references this bug:

Author: mandree
Date: Sat Jul 13 08:31:15 UTC 2019
New revision: 506516
URL: https://svnweb.freebsd.org/changeset/ports/506516

  OpenVPN won't compile with LibreSSL, mark IGNORE.

  Upstream maintainers are massively pushing back against patches
  offered so far with valid and concrete technical reasons and unsuitability
  of the LibreSSL version API that will create a maintenance nightmare.
  (And LibreSSL abusing the OpenSSL API.)

  PR:		238382
  Submitted by:	pizzamig

Comment 8 commit-hook freebsd_committer 2019-07-13 08:40:03 UTC
A commit references this bug:

Author: mandree
Date: Sat Jul 13 08:39:00 UTC 2019
New revision: 506519
URL: https://svnweb.freebsd.org/changeset/ports/506519

  security/openvpn Mark a failing build with LibreSSL "IGNORE"

  MFH: r506516

  OpenVPN won't compile with LibreSSL, mark IGNORE.

  Upstream maintainers are massively pushing back against patches
  offered so far with valid and concrete technical reasons and unsuitability
  of the LibreSSL version API that will create a maintenance nightmare.
  (And LibreSSL abusing the OpenSSL API.)

  Invoking blanket approval since this just marks a non-default configuration
  that is failing "IGNORE", and changes a _DESC.

  PR:		238382
  Submitted by:	pizzamig

  Approved by:	ports-secteam (blanket)

_U  branches/2019Q3/
Comment 9 Luca Pizzamiglio freebsd_committer 2019-07-15 10:35:26 UTC
Hi Matthias,

The first patch I've sent was not ideal and it got somehow rejected by OpenVPN people. I tend to agree.
However, following the feedback (especially the TLS 1.3 one), I updated the patch (see Comment 4) and I've submitted a new one, derived by OpenBSD repo (where they use LibreSSL only) that properly disable TLS 1.3 (for now) if LibreSSL is used.

The second one could be upstreamed, because it has a higher value and more trusted origin (the OpenBSD guys).

It's up to you to try to upstream the new patch or not (probably, a newer version of LibreSSL with TLS 1.3 will change everything again)
Comment 10 Franco Fichtner 2019-07-15 12:44:27 UTC
With all due respect, it is a very disappointing trend to enforce supposed upstream lack of care in an open source project's software catalogue. There is nothing in OpenVPN that breaks with LibreSSL. OPNsense has had this for years and will continue to run it despite these questionable decisions.
Comment 11 Matthias Andree freebsd_committer 2019-07-16 06:30:59 UTC
Valid concerns have been raised about maintainability of the #ifdef mess that is a direct consequence of LibreSSL abusing OpenSSL APIs versioning in an incompatible way (LibreSSL pretending to be OpenSSL 2.0.0), and I understand that the upstream OpenVPN maintainers don't want to mess around with patches where they need to maintain a, say, OpenSSL 1.0.2 interface long after it went out of support because LibreSSL hasn't kept up with the OpenSSL interfaces. (Meaning that they think LibreSSL might be incompatible with any supported OpenSSL version at some future point in time.)

I find the OpenBSD patch a bit awkward because it's checking seemingly unrelated features with all its defined(OPENSSL_NO_TLS1_3). This /silently/ assumes that if you have TLS1_3_VERSION, you also have OPENSSL_NO_TLS1_3 and vice versa. While that is the case in LibreSSL 2.9.2 and they appear to have LIBRESSL_HAS_TLS1_3 guards, LibreSSL make no guarantees, so we'll need to write things in a different way.

I appreciate that losing LibreSSL as a working OpenSSL-"compatible" provider is a recent regression that happened after v2.4.6 (see below) with added TLSv1.3 support, so I am reopening this problem report.


Git bisect log on OpenVPN's repo git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git and branch "release/2.4" identifying the commit that regressed.

git bisect start
# good: [b3a7f452206607fb23d5cea76339dfb164c283f2] preparing release v2.4.6 (ChangeLog, version.m4, Changes.rst)
git bisect good b3a7f452206607fb23d5cea76339dfb164c283f2
# bad: [2b8aec62d5db2c17d5d4052991bc18272748bf29] preparing release v2.4.7 (ChangeLog, version.m4, Changes.rst)
git bisect bad 2b8aec62d5db2c17d5d4052991bc18272748bf29
# good: [78d4f0ad106720d8988e144f6d30ec11d84dee2f] Enable dhcp on tap adapter using interactive service
git bisect good 78d4f0ad106720d8988e144f6d30ec11d84dee2f
# bad: [33253cf1d0c1175e7391a4eec3b64f1ec0b303dd] Use right function to set TLS1.3 restrictions in show-tls
git bisect bad 33253cf1d0c1175e7391a4eec3b64f1ec0b303dd
# good: [266178b7b6280d5f32403ba8780ddbb517e3ac6a] Don't print OCC warnings about 'key-method', 'keydir' and 'tls-auth'
git bisect good 266178b7b6280d5f32403ba8780ddbb517e3ac6a
# bad: [9de7fe0a7bf1111ebea9ca9e28b2def9ae3e53ff] Add support for tls-ciphersuites for TLS 1.3
git bisect bad 9de7fe0a7bf1111ebea9ca9e28b2def9ae3e53ff
# good: [773c086367c8dd94d71a10bd2b32f09b4a0840ae] interactive.c: fix usage of potentially uninitialized variable
git bisect good 773c086367c8dd94d71a10bd2b32f09b4a0840ae
# first bad commit: [9de7fe0a7bf1111ebea9ca9e28b2def9ae3e53ff] Add support for tls-ciphersuites for TLS 1.3