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
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 Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
