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

[Jakob Bohm]

Someone picked up an old dead thread, but I'll make some brief
responses.

On 11/02/2016 20:49, Valerie Anne Fenwick wrote:
>
> Hi Jakob -
>
> On 11/22/15 08:17 PM, Jakob Bohm wrote:
>> On 20/11/2015 23:26, Short, Todd wrote:
>>> While I am all for simplicity, I also think that removing 
>>> functionality is a “bad idea”.
>>>
>>> To reduce the support burden, deprecate the ciphers:
>>> 1. Under support, indicate that these ciphers will no longer receive 
>>> fixes.
>>> 2. Remove any assembly implementations
>>> 3. Disable them by default.
>>>
>>> I suggest following the 80/20 rule (sometimes the 95/5 rule):
>>>
>>> Those “who care” (the minority) about the ciphers can re-enable them 
>>> and rebuild the
>>> library.
>>> Those “who don’t care” (the majority) about the ciphers, should get 
>>> the functionality
>>> that most people care about, basically SSL/TLS connectivity.
>>>
>> You all seem to misunderstand the fundamental release engineering
>> issues involved.
>>
>> 1. Very shortly after you release OpenSSL 1.1.0, many
>>    distributions and pointy haired managers will blindly
>>    switch to the new version as the only version available.
>>     This will not at all await the "end of support" for
>>    OpenSSL 1.0.x .  So breaking changes will cause harm much
>>    sooner than you claim.
>
> As one of those pointy haired managers, I have to say that
> this scenario is simply not possible with the ABI incompatibility
> between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
> have to be updated, too. (unless I'm completely misunderstanding
> something). So, most likely we're looking at a universe where
> both will coexist for awhile (that seems to match up with
> OpenSSL's support plans as well).
This shows you are not pointy-haired enough to fit this
example.
>
> Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
> Both co-existed for quite awhile.
>
However the differences between 0.9.8 and 1.0.0 were
much smaller than the upcoming differences between
1.0.x and 1.1.x .

They are basically removing lots of functionality
for very little gain.

>>
>> 2. Because of the need to easily keep up with routine security
>>    updates to OpenSSL, it is highly impractical to maintain
>>    locally reconfigured build scripts and patches, though some
>>    of us have no choice (and are still struggling with the
>>    massively huge and disorganized code reformatting in the
>>    middle of the 1.0.1 security update series).
>
> I do not envy this work, but we're talking about a security
> toolkit - it should not stay in the past. It's, quite simply,
> dangerous to do so.
>
But it should not do things that leave past "customers"
unprotected because they can no longer use the current
but incompatible toolkit.  Because that in and of itself
is also very dangerous.

>>
>> 3. When distributions upgrade OpenSSL, many applications that
>>    have not been actively and deliberately ported to the new
>>    OpenSSL version will be blindly recompiled with the new
>>    versions, and if they break, random developers with no
>>    understanding of either the application, OpenSSL or even
>>    security will do ill-informed rushed patches to try to undo
>>    the breakage you caused.
>
> Sadly, that happens when any toolkit updates.
Yes, but some updates are more likely to cause such
harm than others.  Thisis the whole reason the entire
computer industryis so keen on backwards compatibility.

>
>>
>> 4. OpenSSL is THE primary crypto library for the FOSS universe.
>>    You may be volunteers, but you are working on a massively
>>    important piece of software, not some random optional library.
>
> Yes, but they are still allowed to change for the better.
>
> GnuTLS did this as well, between their 2.x release and 3.x.
> There is precendence. It is not pain free, but it is what
> we all need to do to make a better and safter internet.
>
> Bad choices made now will haunt us for another 10+ years.
>
I was arguing that they *are* making bad choices now.

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/20160211/db348834/attachment-0001.html>