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