Huge +1. I find Viktor’s arguments more than convincing - irrefutable.
As for “weakening the library”, I don’t find this argument correct. It is not about libssl - it’s about libcrypto. Quite a different animal. -- Regards, Uri Blumenthal On 11/16/15, 18:23 , "openssl-dev on behalf of Matt Caswell" <[email protected] on behalf of [email protected]> wrote: > >Meant to send this to openssl-dev not openssl-users so resending... > >On 16/11/15 15:51, Emilia Käsper wrote: >> Thanks all for your feedback! >> >> I asked for mainstream use-cases for algorithms whose removal could >> cause widespread pain. Some individual users, undoubtedly, will be hit >> by this, and I acknowledge that they may not be reading this list. But I >> wanted to know if I'd missed something endemic. I also asked elsewhere: >> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 >> must stay. >> >> There is a tradeoff: by attempting to accommodate every single use-case, >> we will weaken the library for a substantial amount of our user base, by >> offering them bad defaults, or simply by virtue of the fact that our >> developer resources are not infinite. (Near)-dead code is a liability. > >We can significantly reduce that liability by removing any assembler >optimisations. Also just because something is available doesn't mean it >has to be "default". We can have good defaults whilst keeping old crypto. > > >> >> So far, excluding suspicions that something may be used somewhere, I've >> received one clear argument, for RC5. And, while I'm sympathetic to the >> cause, I believe this is the case where we have to balance one user's >> needs against everyone else's. >> >> As for specific deprecation strategies: >> - Don't forget that all applications will have to recompile against 1.1. >> >> - Disabling algorithms doesn't work well for us as it's just pushing the >> decision on the distros. It also wouldn't win us any resources as we'd >> still be responsible for keeping the code bug-free. The only win would >> be in default compiled code size. > >Disabling algorithms isn't the right answer IMO. I do like the idea of a >"liblegacycrypto". That way people that only have need of current >up-to-date crypto can stick with the main library. Others who need the >older crypto can still get at it. Yes, that means we still have to >maintain this code - but I don't see it as that big a burden. > >> >> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries >> (Python, PHP etc) who correctly account for the fact that an >> implementation may be missing (which they have to, anyway) will continue >> to work. >> >> - Removing assembly support is a GREAT suggestion to simplify the >> complexity, and I think we should do this for anything we end up leaving >> in, and perhaps even for some things not yet on the hit list (RC4?). >> >> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but >> research needs shouldn't prevail over those of real applications. We are >> generally not on the frontline of deprecating things - RC4 isn't yet on >> the list. SSLv3 isn't yet on the list, etc. But we can't become the >> Internet Archive of All Old Crypto either, and there's some cleanup to >> do that's long overdue. > >Being the "swiss army knife" is no bad thing (even where that includes >old crypto). We just have to find a way to separate the two concerns: >current crypto (and only current crypto) for most (and probably most >importantly for libssl users); broader crypto support for those that >want it (which is why I like the liblegacycrypto idea because it enables >us to do that). > > >> It seems to me that these can pretty safely go: >> >> MD2 - (The argument that someone somewhere may want to keep verifying >> old MD2 signatures on self-signed certs doesn't seem like a compelling >> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) >> MDC2 >> SEED >> RC5 > >All candidates for liblegacycrypto IMO rather than deletion. > >Whether this is the right thing to do in the 1.1.0 timeframe is another >consideration though. Viktor's arguments are quite convincing. > >Matt > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
