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

[Blumenthal, Uri - 0553 - MITLL]

On 11/19/15, 5:01 , "openssl-dev on behalf of Tomas Mraz"
<openssl-dev-bounces at openssl.org on behalf of tmraz at redhat.com> wrote:

>On Čt, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote:
>> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:
>> 
>>> I guess I'm just having a hard time wrapping my head around why, upon
>> > hearing that the volunteer-run project is giving years' advance notice
>> > that certain features will be removed, the response is insistence that
>> > everything must remain supported forever, instead of using the advance
>> > notice to investigate alternatives.  Volunteers should be allowed to
>> > ease up when they need to, after all.
>> 
>> Culture-clash.  Security culture says everything remotely weak must
>> go, but release-engineering culture emphasizes compatibilty.  The
>> crypto library is more of a systems component, not a security
>> component.  The SSL library is more of a security component than
>> a systems component, and has algorithm negotiation.
>
>What about some reasonable middle ground?
>1. remove all assembler implementations of not-current crypto

Yes, certainly. Legacy stuff is supposed to work. It may work slower.

>2. remove all references of it from the libssl

Yes, certainly. After all, this is where most of the threats and risks
live.

>3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
>OpenSSL_add* functions so the users have to explicitly add these to use
>them automatically.

Probably yes. Cannot judge the full impact off-hand, but it makes sense.

>In future it might be even reasonable to move the implementations into
>the libcryptolegacy.so however I am not sure this change is worth it for
>1.1.0.

I doubt that such a split would make sense.

> 
>I believe the maintenance costs for pure C implementations in such
>separate libcryptolegacy or even in the main C library would be quite
>minimal. 

100% concur, based on my experience maintaining code (going back enough
decades to know :).

>I would also expect the users of such legacy code to step up
>with sharing the maintenance costs.

Possibly. Though, as was pointed out, it is often unclear if you are or
are not a user - can you tell for certain what crypto mechanisms (if any)
protect your archives going back to the oldest one you keep?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4308 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151119/1ac32195/attachment.bin>