<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Someone picked up an old dead
thread, but I'll make some brief </tt><tt><br>
</tt><tt>responses.</tt><tt><br>
</tt><tt><br>
</tt><tt>On 11/02/2016 20:49, Valerie Anne Fenwick wrote:</tt><tt><br>
</tt></div>
<blockquote class=" cite" id="mid_56BCE5B9_5010705_oracle_com"
cite="mid:56BCE5B9.5010705@oracle.com" type="cite">
<tt><br>
</tt><tt>Hi Jakob -
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>On 11/22/15 08:17 PM, Jakob Bohm wrote:
</tt><tt><br>
</tt>
<blockquote class=" cite" id="Cite_1377805" type="cite"><tt>On
20/11/2015 23:26, Short, Todd wrote:
</tt><tt><br>
</tt>
<blockquote class=" cite" id="Cite_7386599" type="cite"><tt>While
I am all for simplicity, I also think that removing
functionality is a “bad idea”.
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>To reduce the support burden, deprecate the ciphers:
</tt><tt><br>
</tt><tt>1. Under support, indicate that these ciphers will no
longer receive fixes.
</tt><tt><br>
</tt><tt>2. Remove any assembly implementations
</tt><tt><br>
</tt><tt>3. Disable them by default.
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>I suggest following the 80/20 rule (sometimes the
95/5 rule):
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>Those “who care” (the minority) about the ciphers can
re-enable them and rebuild the
</tt><tt><br>
</tt><tt>library.
</tt><tt><br>
</tt><tt>Those “who don’t care” (the majority) about the
ciphers, should get the functionality
</tt><tt><br>
</tt><tt>that most people care about, basically SSL/TLS
connectivity.
</tt><tt><br>
</tt>
<tt><br>
</tt></blockquote>
<tt>You all seem to misunderstand the fundamental release
engineering
</tt><tt><br>
</tt><tt>issues involved.
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>1. Very shortly after you release OpenSSL 1.1.0, many
</tt><tt><br>
</tt><tt> distributions and pointy haired managers will
blindly
</tt><tt><br>
</tt><tt> switch to the new version as the only version
available.
</tt><tt><br>
</tt><tt> This will not at all await the "end of support" for
</tt><tt><br>
</tt><tt> OpenSSL 1.0.x . So breaking changes will cause harm
much
</tt><tt><br>
</tt><tt> sooner than you claim.
</tt><tt><br>
</tt></blockquote>
<tt><br>
</tt><tt>As one of those pointy haired managers, I have to say
that
</tt><tt><br>
</tt><tt>this scenario is simply not possible with the ABI
incompatibility
</tt><tt><br>
</tt><tt>between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications
will
</tt><tt><br>
</tt><tt>have to be updated, too. (unless I'm completely
misunderstanding
</tt><tt><br>
</tt><tt>something). So, most likely we're looking at a universe
where
</tt><tt><br>
</tt><tt>both will coexist for awhile (that seems to match up with
</tt><tt><br>
</tt><tt>OpenSSL's support plans as well).
</tt><tt><br>
</tt></blockquote>
<tt>This shows you are not pointy-haired enough to fit this </tt><tt><br>
</tt><tt>
example.</tt><tt><br>
</tt><tt>
</tt>
<blockquote class=" cite" id="mid_56BCE5B9_5010705_oracle_com"
cite="mid:56BCE5B9.5010705@oracle.com" type="cite">
<tt><br>
</tt><tt>Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
</tt><tt><br>
</tt><tt>Both co-existed for quite awhile.
</tt><tt><br>
</tt>
<tt><br>
</tt></blockquote>
<tt>However the differences between 0.9.8 and 1.0.0 were </tt><tt><br>
</tt><tt>much </tt><tt>smaller than the upcoming differences
between </tt><tt><br>
</tt><tt>1.0.x and 1.1.x .</tt><tt><br>
</tt><tt><br>
</tt><tt>They are basically removing lots of </tt><tt>functionality</tt><tt>
</tt><tt><br>
</tt><tt>for very little gain.</tt><tt><br>
</tt><tt><br>
</tt>
<blockquote class=" cite" id="mid_56BCE5B9_5010705_oracle_com"
cite="mid:56BCE5B9.5010705@oracle.com" type="cite">
<blockquote class=" cite" id="Cite_9950516" type="cite">
<tt><br>
</tt><tt>2. Because of the need to easily keep up with routine
security
</tt><tt><br>
</tt><tt> updates to OpenSSL, it is highly impractical to
maintain
</tt><tt><br>
</tt><tt> locally reconfigured build scripts and patches,
though some
</tt><tt><br>
</tt><tt> of us have no choice (and are still struggling with
the
</tt><tt><br>
</tt><tt> massively huge and disorganized code reformatting in
the
</tt><tt><br>
</tt><tt> middle of the 1.0.1 security update series).
</tt><tt><br>
</tt></blockquote>
<tt><br>
</tt><tt>I do not envy this work, but we're talking about a
security
</tt><tt><br>
</tt><tt>toolkit - it should not stay in the past. It's, quite
simply,
</tt><tt><br>
</tt><tt>dangerous to do so.
</tt><tt><br>
</tt>
<tt><br>
</tt></blockquote>
<tt>But it should not do things that leave past "customers" </tt><tt><br>
</tt><tt>unprotected because they can no longer use the current </tt><tt><br>
</tt><tt>but incompatible toolkit. Because that in an</tt><tt>d of
itself </tt><tt><br>
</tt><tt>is </tt><tt>also very dangerous.</tt><tt><br>
</tt><tt><br>
</tt>
<blockquote class=" cite" id="mid_56BCE5B9_5010705_oracle_com"
cite="mid:56BCE5B9.5010705@oracle.com" type="cite">
<blockquote class=" cite" id="Cite_606051" type="cite">
<tt><br>
</tt><tt>3. When distributions upgrade OpenSSL, many
applications that
</tt><tt><br>
</tt><tt> have not been actively and deliberately ported to
the new
</tt><tt><br>
</tt><tt> OpenSSL version will be blindly recompiled with the
new
</tt><tt><br>
</tt><tt> versions, and if they break, random developers with
no
</tt><tt><br>
</tt><tt> understanding of either the application, OpenSSL or
even
</tt><tt><br>
</tt><tt> security will do ill-informed rushed patches to try
to undo
</tt><tt><br>
</tt><tt> the breakage you caused.
</tt><tt><br>
</tt></blockquote>
<tt><br>
</tt><tt>Sadly, that happens when any toolkit updates.
</tt><tt><br>
</tt></blockquote>
<tt>Yes, but some updates are more likely to cause such </tt><tt><br>
</tt><tt>harm than others. This</tt><tt> is the whole reason the
entire </tt><tt><br>
</tt><tt>computer industry</tt><tt> is so keen on backwards
compatibility.</tt><tt><br>
</tt><tt><br>
</tt>
<blockquote class=" cite" id="mid_56BCE5B9_5010705_oracle_com"
cite="mid:56BCE5B9.5010705@oracle.com" type="cite">
<tt><br>
</tt>
<blockquote class=" cite" id="Cite_3119040" type="cite">
<tt><br>
</tt><tt>4. OpenSSL is THE primary crypto library for the FOSS
universe.
</tt><tt><br>
</tt><tt> You may be volunteers, but you are working on a
massively
</tt><tt><br>
</tt><tt> important piece of software, not some random
optional library.
</tt><tt><br>
</tt></blockquote>
<tt><br>
</tt><tt>Yes, but they are still allowed to change for the better.
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>GnuTLS did this as well, between their 2.x release and
3.x.
</tt><tt><br>
</tt><tt>There is precendence. It is not pain free, but it is what
</tt><tt><br>
</tt><tt>we all need to do to make a better and safter internet.
</tt><tt><br>
</tt>
<tt><br>
</tt><tt>Bad choices made now will haunt us for another 10+ years.
</tt><tt><br>
</tt>
<tt><br>
</tt></blockquote>
<tt>I was arguing that they *are* making bad choices now.</tt><tt><br>
</tt><tt><br>
</tt>
<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>