[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150611194707.GA6871@openwall.com>
Date: Thu, 11 Jun 2015 22:47:08 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: OpenSSL
On Thu, Jun 11, 2015 at 09:54:39PM +0300, Solar Designer wrote:
> 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
Without *-cve* and *-fips* patches, this looks better:
$ find -name 'openssl*.patch' -type f | egrep -ve '-cve|-fips' | wc -l
52
$ wc `find -name 'openssl*.patch' -type f | egrep -ve '-cve|-fips'` | tail -1
13130 50251 416652 total
Presumably, the *-cve* patches are all backports from newer upstream or
similar.
Fedora is currently at 1.0.2a, and has fewer patches:
http://pkgs.fedoraproject.org/cgit/openssl.git/tree/
> 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.
Gremlin went with keeping Red Hat's soname anyway, even in a package
based on 1.0.2a. I'm not sure if this is justified. It'd take some
code review to see if binary compatibility is maintained.
Red Hat introduces symbol versioning for SSLeay() and SSLeay_version()
to return old version number/string when not linked against 1.0.1:
https://git.centos.org/blob/rpms!openssl/a5ef24ffb32f05cda7549bde8c2565250342fa4f/SOURCES!openssl-1.0.1e-version.patch
I don't know if we want to have this or not. Returning their "OpenSSL
1.0.0-fips 29 Mar 2010" string would be weird if we exclude their FIPS
stuff.
openssl-1.0.1e-compat-symbols.patch introduces 3 dummy functions
FIPS_corrupt_dsa_keygen(), ENGINE_load_aesni(), and FIPS_rand_check()
compatibility.
openssl-1.0.1-beta2-dtls1-abi.patch moves a struct field closer to the
end of struct. We already have this patch as
openssl-1.0.0-beta4-rh-dtls1-abi.diff, and in our case it actually moves
the field to the very end of struct. We also have this patch prefixed
by its description:
"Adding struct member is ABI breaker however as the structure is always
allocated by the library calls we just move it to the end and it should
be reasonably safe."
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.
