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

[Jakob Bohm]

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.

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).

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.

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.

5. In these times of panic and marshal law, it is essential
   that the key resources for open source crypto remain
   unrestrained by the politics of any single country, such that
   the sudden outlawing of crypto in the current home of the
   maintainers does not prevent the project from being continued
   by a different team in a different country.  This makes it
   essential not to tie any legal or technical aspect to a single
   place, country, political alliance, company or person.  It is
   also critical to avoid any and all legal ties to the
   historically most problematic jurisdictions, such as the US.
    So don't pay people through any US bank accounts, foundations
   or legal entities.  Don't keep any technical assets (such as
   repositories or mail archives) in one country.  Don't create
   legal documents that tie any license permissions to any
   specific country or organization.
    These same considerations exclude any of the US based
   libraries and forks from being relevant outside that country.

6. All of this requires a lot more caution and a lot less
   arrogance from the people making decisions about changes
   in the OpenSSL library and project.


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