Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jun 2015 21:54:39 +0300
From: Solar Designer <>
Subject: OpenSSL


We're currently using OpenSSL 1.0.0* with relatively few, relatively
small patches:

build@...t:~/native/Owl/packages/openssl $ echo *.diff | wc -w
build@...t:~/native/Owl/packages/openssl $ wc *.diff
   24    72   836 openssl-0.9.8b-rh-test-use-localhost.diff
   25   118   942 openssl-1.0.0-beta4-rh-dtls1-abi.diff
   23    87   933 openssl-1.0.0b-gosta-pkcs12-fix.diff
   14    40   345 openssl-1.0.0b-owl-alt-issetugid.diff
   95   308  3403 openssl-1.0.0b-rh-alt-soversion.diff
   74   174  2004 openssl-1.0.0b-rh-default-paths.diff
   39   111   976 openssl-1.0.0b-rh-enginesdir.diff
   13    47   490 openssl-1.0.0b-rh-env-nozlib.diff
   11    43   503 openssl-1.0.0b-rh-rpath.diff
   49   135  1251 openssl-1.0.0b-rh-version-engines.diff
   29    91   723 openssl-1.0.0b-rh-x509.diff
  137   530  5425 openssl-1.0.0d-suse-env.diff
   31    85   802 openssl-1.0.0m-owl-warnings.diff
   42   198  2188 openssl-1.0.0m-rh-cipher-change.diff
   97   457  4449 openssl-1.0.0o-rh-owl-man.diff
  703  2496 25270 total

We can continue updating to new releases in the 1.0.0 branch, but it's
scheduled to be EOL'ed with the end of this year and it lacks TLS 1.1
and 1.2 support, which in turn is apparently required by recent versions
of Chrome (I'm told that it warns users when a server uses TLS 1.0 or
SSL).  So it appears that we need to move to the 1.0.1 or 1.0.2 branch,
or to LibreSSL or BoringSSL.

Red Hat moved to OpenSSL 1.0.1 in RHEL 6.5:

I looked into moving to OpenSSL 1.0.1 today.

Good news: Red Hat retained the soname when they updated to 1.0.1.
Also, RHEL7 is also still at the 1.0.1 branch, and still with the same
soname, so we could maintain compatibility with RHEL6 and RHEL7 at once.

Bad news: the number and sizes of Red Hat patches are large, and they're
all relative to 1.0.1e, which is rather old (current upstream is
1.0.1n).  (Actually, some are against much older versions and still not
regenerated, but apparently they apply to 1.0.1e fine.)  Also, many of
the patches look moderately problematic to me, e.g. their
openssl-1.0.0-beta5-readme-warning.patch documents
openssl-1.0.1e-env-zlib.patch implements OPENSSL_DEFAULT_ZLIB instead
(with OPENSSL_NO_DEFAULT_ZLIB nowhere to be found).  It'd be quite some
work to clean all of this up, and it'd feel like a waste of time.

RHEL6 (openssl-1.0.1e-30.el6_6.9.src.rpm):

$ echo *.patch | wc -w
$ wc *.patch | tail -1
  34330  132508 1050445 total

CentOS 7:

git clone -b c7 c7-openssl

Version: 1.0.1e
Release: 42%{?dist}.6

$ echo *.patch | wc -w
$ wc *.patch | tail -1
  43186  165916 1305364 total

It looks like our options are:

1. Just keep updating within the 1.0.0 branch while we can.  And I'm not
sure what's next... do our own backports of critical fixes?  But this
does not give us TLS 1.1+.

2. Spend/waste time on selectively applying, forward-porting, and fixing
patches from Red Hat's package to latest 1.0.1 (currently to 1.0.1n).

3. Create a tarball of OpenSSL 1.0.1e + Red Hat's patches and treat that
as our upstream.  Only apply our own tiny patches on top of that.
Drawbacks: dirty stuff (maybe worse than OpenSSL upstream's), deviation
from original upstream, delay with getting security fixes.

4. Ignore Red Hat's patches, just package upstream OpenSSL's code with
our patches.  Drawback: then we're not justified to keep Red Hat's
soname, so we break binary compatibility with RHEL.

5. Move to LibreSSL or BoringSSL.  This is similar to the above, except
that these have their own non-trivial pros and cons compared to OpenSSL.

6. Give up on Owl.

I feel that deciding on this should be part of a bigger decision on
where Owl is heading.  Should it still maintain any RHEL compatibility?
If not, then is there sufficient reason for us to use RPM and to
continue building Owl as a Linux distro?  I mean, there's lots of crap
not only in OpenSSL and RHEL, but also in RPM and in the Linux kernel,
but we chose those for compatibility.  So if we start to drop
compatibility, then how far do we go?  And does our project still make
sense then?

Previously, we'd choose option 2 from the list above, but at this time
I'm not sure.  I'd like to minimize the effort spent on maintenance, and
to direct more effort to doing new and longer term beneficial things.


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ