<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/11/2015 21:36, Karl Vogel wrote:<br>
</div>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<blockquote class=" cite" id="Cite_7755770" type="cite">
<blockquote class=" cite" id="Cite_3193087" type="cite">
<pre wrap="">On Mon, 23 Nov 2015 05:17:33 +0100,
Jakob Bohm <a class="moz-txt-link-rfc2396E" href="mailto:jb-openssl@wisemo.com"><jb-openssl@wisemo.com></a> said:
</pre>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<tt>I am saying that some distributions will switch to the <br>
branch currently planned to be named 1.1.0 long before <br>
support for 1.0.2 ends. And those distributions will <br>
then run try to routinely recompile all openSSL-<br>
referencing software packages against the new OpenSSL <br>
(along with the new libc, the new kernel, the new zlib <br>
etc. etc.) and dispatch bug fixers to fix the resulting <br>
compile errors with no special considerations for crypto <br>
expertise.</tt><tt> (More on this later in this e-mail).<br>
<br>
By the time such an 1.1.0-based OS release is shipped, <br>
that 1.1.0 code will probably be a few letter-patches <br>
behind the latest upstream, at least in name (some <br>
distributions backport the changes but don't change <br>
the letter in the version number, naming it instead <br>
something like 1.1.0d+ourpatch7).<br>
</tt><br>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<tt>I am talking about the breakage caused by PHBs that <br>
insist on using the highest OpenSSL version listed <br>
as "fixed" in the most recent CVE entry, even when <br>
a letter patch to an earlier branch is equally safe. <br>
This combined with code that has not (for any <br>
reason) been ported from 1.0.2 to 1.1.0 by its <br>
primary authors, perhaps because they need some <br>
feature</tt><tt> removed in 1.1.0.<br>
<br>
</tt>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<tt>I am talking about applying usage/application specific <br>
patches to the OpenSSL source tree and the fact that the <br>
reformatting requires all such patches to be reimplemented <br>
one by one to apply to the reformatted code.<br>
<br>
</tt>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<tt>You are talking about internal corporate careful roll-out <br>
procedures, I am talking about OS distributions such as <br>
*BSD and *Linux doing their usual preparations for a new <br>
OS release by importing new versions of upstream sources, <br>
recompiling and fixing obvious bugs until it "looks OK", <br>
while failing to detect subtle breakage or new security <br>
issues.<br>
<br>
A classic example is how Debian (a few years back) did a <br>
patch to the OpenSSL RNG, creating an RNG that worked but <br>
had way too little entropy. It is that kind of crypto-<br>
unskilled mistakes that I fear will proliferate in the <br>
fall-out from the breaking changes in OpenSSL 1.1.0.<br>
<br>
</tt><tt></tt>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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).</pre>
</blockquote>
<tt>It would be more interesting to compare to teams such as <br>
the volunteers on the Linux kernel teams and how they deal <br>
with user mode API compatibility.</tt><br>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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?</pre>
</blockquote>
<tt>It is just another (unrelated) set of mistakes happening <br>
in the new OpenSSL team after the large infusion of money.</tt><br>
<blockquote class=" cite"
id="mid_20151123203637_GA12739_bsd118_area52_afnoapps_usaf_mil"
cite="mid:20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<tt>Saying "we here you" and then high-handedly deciding to <br>
do the deed anyway would also count as arrogance in my book.</tt><br>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>