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

Richard Moore richmoore44 at gmail.com
Thu Nov 19 20:15:49 UTC 2015


On 19 November 2015 at 19:28, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Thu, Nov 19, 2015 at 05:07:38PM +0000, Richard Moore wrote:
>
> >​Yes, but a several people (including me) disagree with you. And one of
> the
> > options that has been suggested is to keep the code but have it disabled
> by
> > default.
>
> Note, we're talking about "disabled" as opposed to "not compiled".
> Stuff that's not compiled by default tends to not get tested, and
> breaks silently when it is needed.  That's not terribly useful.
>

​I haven't seen anything that suggests that actually. ​In fact my
assumption is the opposite of yours.



> (Yes, I know about RC5, which is not compiled by default for IPR
> reasons.  Distributions that have never shipped IDEA compiled-in
> can disable it downstream).
>
> This means that absent explicit compile-time directives, the EVP
> interface will not expose the legacy algorithms.  Middleware that
> provides general-purpose crypto interfaces on top of OpenSSL to
> other software will need to enable the legacy algorithms.
>
> I am not convinced that making people jump through the extra hoops
> would be worth the effort on our part and theirs.  Whom would we
> be helping?
>

​Again, since the old middleware would need to change​ either way, I don't
see why the baggage should be brought along.


> The simplest thing to do is to make legacy libcrypto code maximally
> maintainable, and if removing assembly support does that, than we
> do that.  Beyond that, do nothing.  What algorithms people use on
> their own data is their choice and risk decision not ours.
>
>
​The simplest thing depends on your point of view. The simplest thing if
you only care about openssl is to remove it, however the simplest thing if
you only care about an end product that depends on some weird feature is to
change nothing. You can't just make an absolute statement, as usual there
are trade-offs and work for different people. ​

​Cheers

Rich.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151119/535aa7d9/attachment.html>


More information about the openssl-dev mailing list