On Tue, 2015-11-17 at 00:01 +0000, Viktor Dukhovni wrote: On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote:
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. What becomes a bit tricky is having an EVP interface that can find the algorithms in liblegacrypto. This I think means two different builds of the crypto library, one that depends on liblegacycrypto and provides its algorithms, and another than does not. Is this beyond the necessity to register EVP algorithms? If not, a simple function call to register the legacy crypto functions, which would be contained in the legacy library, should be enough. Some applications might be linked directly to "-secure" or "-compat" to make sure they get one or the other. This is a bunch of work. If you're going to re-link at all, then the above suggestion seems like less cost. For the legacy library, it would simply be maintained as if it were a 3rd party add-on.
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
