On 19/02/17 05:48, Илья Шипицин wrote:
> 2017-02-19 4:16 GMT+05:00 David Sommerseth
> <open...@sf.lists.topphemmelig.net
> <mailto:open...@sf.lists.topphemmelig.net>>:
>     On 18/02/17 08:34, Илья Шипицин wrote:
>     >     I added openssl-1.0.1e to test matrix (do not pay attention to
>     >     commit title, it happened accidently from iPad), so ...
>     >
>     >     https://travis-ci.org/OpenVPN/openvpn/jobs/202709493
>     <https://travis-ci.org/OpenVPN/openvpn/jobs/202709493>
>     >
>     > t_cltsrv.sh + openssl-1.0.1f  = OK
>     > t_cltsrv.sh + openssl-1.0.1e = FAIL
>     Okay, lets get a few important details straight first.  When I spoke
>     about openssl-1.0.1e, it was in an RHEL context (including CentOS and
>     Scientific Linux).  In reality, that is not the same version as OpenSSL
>     upstream 1.0.1e.  Red Hat employs people to backport bugfixes and
>     security fixes from newer OpenSSL 1.0.x releases to 1.0.1e. So the
>     OpenSSL _baseline_ is 1.0.1e [1].  But it must not be compared directly
>     against v1.0.1e from openssl.org <http://openssl.org>.  The baseline
>     defines a /stable ABI/
>     (Application Binary Interface) which applications linking against the
>     library can rely on.  This is what makes RHEL and the clones so stable
>     over 7-10++ years.  And this is the challenge backporters in Red Hat
>     struggle with; not breaking applications which works.
>     So unless I have misunderstood your travis commit ... you set the
>     version to 1.0.1e regardless of Linux distribution.  This itself does
>     not provide any real value for us.  As there are a lot of bugfixes and
>     security implemented in the OpenSSL package RHEL ships ... you can get
>     an idea by looking at the changelog of the openssl RPM package:
> <https://git.centos.org/blob/rpms!!openssl/1c5d99a56e70d3f668fd69f148538c635dd990d6/SPECS!openssl.spec#L642
> <https://git.centos.org/blob/rpms%21%21openssl/1c5d99a56e70d3f668fd69f148538c635dd990d6/SPECS%21openssl.spec#L642>>
>     RHEL6 was released in May 2010 while RHEL7 in June 2014.  What you see
>     above is the changelog for RHEL7.  If my count is correct, that is
>     currently 127 patches *on top of* the upstream OpenSSL v1.0.1e.  I
>     wouldn't expect this patch list to be much longer on RHEL 6 though.
>     So unless your travis script is clever enough to only test OpenSSL
>     v1.0.1e on RHEL, CentOS or ScientificLinux *or* build OpenSSL using the
>     CentOS source RPM ... then I am not surprised things may fail.  Red Hat
>     may very well have fixed some bugs which we're hitting.
> well, RedHat not only ship their very own openssl, but also their own
> openvpn package
> https://dl.fedoraproject.org/pub/epel/7/SRPMS/o/

The Fedora EPEL packages are not really Red Hat (even though many Red
Hatters maintain EPEL packages).  The difference is, EPEL packages are
unsupported by Red Hat's support plans.  Packages coming from the
official Red Hat source repositories (which CentOS "clones"), are fully
supported by their support plans.

> I see, there's %check section, but it is commented. Not sure how thay
> test it. We should get in touch with redhat people if we want openvpn
> properly tested and packaged

OpenVPN is not tested by Red Hat.  Official packages by Red Hat (from
the proper RHEL repositories) go through a massive QE process, with
loads of automated regression testing, specially written for each
distributed package.  All bugzillas tied to a package gets its own test
case written and is explicitly tested.  Then the package is installed,
uninstalled, upgraded and downgraded on systems which tries to simulate
a production environment.  And I've probably forgotten a bunch of other
steps as well.

> I'll have a look at 'make check' under centos later

You won't find any explicit OpenVPN package in the CentOS 6 or later
repositories.  You will find el5 packages though, as OpenVPN was an
official package in RHEL5 (but that is 2.1_rc-something, IIRC)

As of RHEL 6, Red Hat removed OpenVPN from the official repositories and
decided users needing it should use Fedora EPEL for it.  The reasoning
is probably to cost related.  Otherwise they need to allocate at least
on person to be the package maintainer, plus the QE and release
management machinery.  If few Enterprise customers depend on OpenVPN for
their critical workloads, it probably wasn't worth the cost.  In
addition they might have looked at the stability and the amount of
security related issues in OpenVPN over many years (which are quite good!)

But things may change again.  I heard recently that Red Hat is migrating
over to OpenVPN as the only internal IT supported VPN solution.  So
about 10k employees will soon depend on OpenVPN for their daily VPN
need.  We will see when RHEL 8 gets released :)

kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to