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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
