[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jakob Bohm]

On 23/11/2015 21:36, Karl Vogel wrote:
>>> On Mon, 23 Nov 2015 05:17:33 +0100,
>>> Jakob Bohm <jb-openssl at wisemo.com> said:
> J> You all seem to misunderstand the fundamental release engineering issues
> J> involved.
>
>     Actually, we don't.
>
> J> 1.  Very shortly after you release OpenSSL 1.1.0, many distributions
> J> and pointy haired managers will blindly switch to the new version as
> J> the only version available.
>
>     I've installed new OS releases and distributions for over 20 years,
>     and I don't ever remember having that particular problem with OpenSSL.
>     On the contrary, our vendors are very conservative and I frequently end
>     up replacing their version.
I am saying that some distributions will switch to the
branch currently planned to be named 1.1.0 long before
support for 1.0.2 ends.  And those distributions will
then run try to routinely recompile all openSSL-
referencing software packages against the new OpenSSL
(along with the new libc, the new kernel, the new zlib
etc. etc.) and dispatch bug fixers to fix the resulting
compile errors with no special considerations for crypto
expertise.  (More on this later in this e-mail).

By the time such an 1.1.0-based OS release is shipped,
that 1.1.0 code will probably be a few letter-patches
behind the latest upstream, at least in name (some
distributions backport the changes but don't change
the letter in the version number, naming it instead
something like 1.1.0d+ourpatch7).

> J> This will not at all await the "end of support" for OpenSSL 1.0.x.
> J> So breaking changes will cause harm much sooner than you claim.
>
>     If we'd waited for the lowest common denominators (aka PHBs) to start
>     doing their jobs right, we'd still be using DOS 5 and looking forward
>     to that new-fangled windows thing.
I am talking about the breakage caused by PHBs that
insist on using the highest OpenSSL version listed
as "fixed" in the most recent CVE entry, even when
a letter patch to an earlier branch is equally safe.
  This combined with code that has not (for any
reason) been ported from 1.0.2 to 1.1.0 by its
primary authors, perhaps because they need some
featureremoved in 1.1.0.

>
> J> 2.  Because of the need to easily keep up with routine security updates to
> J> OpenSSL, it is highly impractical to maintain locally reconfigured build
> J> scripts and patches, though some of us have no choice (and are still
> J> struggling with the massively huge and disorganized code reformatting
> J> in the middle of the 1.0.1 security update series).
>
>     Do you mean reformatting or refactoring?  Would the API itself undergo
>     significant changes just because some obsolete crypto was removed?
>     Not being snarky, honestly curious.
>
>     I understand that people do more complex things than simply install
>     the openssl binary and associated libraries, but I keep CentOS-6,
>     Solaris-10, and Solaris-11 boxes patched with the same set of scripts.
>     Aside from the (rare) portability tweak, I don't touch them.
I am talking about applying usage/application specific
patches to the OpenSSL source tree and the fact that the
reformatting requires all such patches to be reimplemented
one by one to apply to the reformatted code.

>
> J> 3.  When distributions upgrade OpenSSL, many applications that have not
> J> been actively and deliberately ported to the new OpenSSL version will
> J> be blindly recompiled with the new versions, and if they break, random
> J> developers with no understanding of either the application, OpenSSL or
> J> even security will do ill-informed rushed patches to try to undo the
> J> breakage you caused.
>
>     If you blindly recompile *anything* just because a version number
>     changed, any resulting breakage is YOUR problem.  People who understand
>     release engineering issues know better; they also know how to read a
>     changelog and tell their customers when (and why) to expect something
>     different.
>
>     When OpenSSL-1.1.whatever comes out, I'll do the same thing I've
>     always done -- wait a bit for the initial reactions, install it on my
>     workstation first to make sure it doesn't barf, and then move it out
>     to the production boxes.
You are talking about internal corporate careful roll-out
procedures, I am talking about OS distributions such as
*BSD and *Linux doing their usual preparations for a new
OS release by importing new versions of upstream sources,
recompiling and fixing obvious bugs until it "looks OK",
while failing to detect subtle breakage or new security
issues.

A classic example is how Debian (a few years back) did a
patch to the OpenSSL RNG, creating an RNG that worked but
had way too little entropy.  It is that kind of crypto-
unskilled mistakes that I fear will proliferate in the
fall-out from the breaking changes in OpenSSL 1.1.0.

>
> J> 4.  OpenSSL is THE primary crypto library for the FOSS universe.
> J> You may be volunteers, but you are working on a massively important
> J> piece of software, not some random optional library.
>
>     Most of them *are* volunteers, and they seem to be taking their
>     work more seriously than the people disparaging them, not to mention
>     the folks who are supposed to get this right (i.e., U.S. Office of
>     Personnel Management).
It would be more interesting to compare to teams such as
the volunteers on the Linux kernel teams and how they deal
with user mode API compatibility.
>
> J> 5.  In these times of panic and marshal law, it is essential that the
> J> key resources for open source crypto remain unrestrained by the politics
> J> of any single country...
>
>     What does this have to do with removing obsolete crypto from a library?
It is just another (unrelated) set of mistakes happening
in the new OpenSSL team after the large infusion of money.
>
> J> 6.  All of this requires a lot more caution and a lot less arrogance
> J> from the people making decisions about changes in the OpenSSL library
> J> and project.
>
>     "Arrogance" would be slamming the changes in without discussion or
>     notification and saying "like it or lump it".  Haven't seen that.
Saying "we here you" and then high-handedly deciding to
do the deed anyway would also count as arrogance in my book.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151124/10d2d9e9/attachment-0001.html>