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
> 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.  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:

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.

kind regards,

David Sommerseth
OpenVPN Technologies, Inc

[1] The reason is that all the _baseline_ packages in major RHEL
    releases are certified against a lot of hardware (IBM, HP, Dell,
    EMC, NetApp, etc, etc) and third party software (SAP, Oracle, etc,
    etc).  So rebasing is out of question, as that requires new, time
    consuming and expensive re-certifications.  Which is why you
    extremely seldom see version updates on packages.  Those few times
    that happens, it is usually considered to not break any important
    certifications.  Like, a SAP server installation probably don't
    have any dependencies against the GNOME 3 packages.

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