On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: > The simplest approach is to remove ciphersuites from the SSL/TLS > code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), > but leave the underlying crypto in the library. > > Similarly, one might remove algorithms from S/MIME, CMS, ... while > leaving them in the base crypto library.
FWIW, this is one of the consequences of OpenSSL providing both libcrypto and libssl. It would be nice from a maintenance perspective to be able to decouple the two more cleanly. I definitely like Viktor's suggestion of removing known-bad mechanisms from libssl. It's harder to know what to do with libcrypto. Perhaps it would be useful to gather data on this by looking at large codebases (e.g. large linux distros like fedora or debian) to see whether these particular functions of libcrypto are being used or linked to. I haven't had the time to do a full review here, but i've found https://codesearch.debian.net/ useful for this kind of API deprecation/removal in the past. e.g.: https://codesearch.debian.net/perpackage-results/MDC2/2/page_0 Unfortunately, OpenSSL has lots of bindings to other languages, so the binding authors themselves might say "we use these functions and offer them to our users", which means there's a chained set of dependencies to consider for proper deprecation. Will removal of these primitives mean that the language bindings won't build against newer versions of OpenSSL? --dkg _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
