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
