[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150611185439.GA6524@openwall.com>
Date: Thu, 11 Jun 2015 21:54:39 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: OpenSSL
Hi,
We're currently using OpenSSL 1.0.0* with relatively few, relatively
small patches:
build@...t:~/native/Owl/packages/openssl $ echo *.diff | wc -w
15
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:
https://securityblog.redhat.com/2013/12/11/tlsv1-1-and-tlsv1-2-now-available-in-rhel/
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_NO_DEFAULT_ZLIB in top-level README, but
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
83
$ wc *.patch | tail -1
34330 132508 1050445 total
CentOS 7:
git clone https://git.centos.org/git/rpms/openssl.git -b c7 c7-openssl
Version: 1.0.1e
Release: 42%{?dist}.6
$ echo *.patch | wc -w
91
$ 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.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
