On 17/11/15 00:01, 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 just limited to OpenSSL_add_all_algorithms()/OpenSSL_add_all_ciphers()/OpenSSL_add_all_digests()? How about if those were macros that just picked up the relevant implementation based on a define. So in evp.h, something like: #ifdef OPENSSL_LEGACY_ALGS void OpenSSL_add_all_legacy_algorithms(); void OpenSSL_add_all_legacy_ciphers(); void OpenSSL_add_all_legacy_digests(); #define OpenSSL_add_all_algorithms() OpenSSL_add_all_legacy_algorithms() #define OpenSSL_add_all_ciphers() OpenSSL_add_all_legacy_ciphers() #define OpenSSL_add_all_digests() OpenSSL_add_all_legacy_digests() #else void OpenSSL_add_all_main_algorithms(); void OpenSSL_add_all_main_ciphers(); void OpenSSL_add_all_main_digests(); #define OpenSSL_add_all_algorithms() OpenSSL_add_all_main_algorithms() #define OpenSSL_add_all_ciphers() OpenSSL_add_all_main_ciphers() #define OpenSSL_add_all_digests() OpenSSL_add_all_main_digests() #endif OpenSSL_add_all_legacy_ciphers() would call OpenSSL_add_all_main_ciphers() and add all the legacy ones in too. Similarly for the other functions. Then you just compile apps which don't need legacy support with "-lcrypto", and apps that do with "-DOPENSSL_LEGACY_ALGS -lcrypto -lcrypto-legacy" > > Systems might then ship with: > > libcrypto-legacy.so - Just the legacy algorithms > > libcrypto-compat.so - Libcrypto that supports the above > libcrypto-secure.so - Libcrypto with just the strong algos > > libcrypto.so - Symlink to one of the two above > > 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. I don't think you would need libcrypto-compat if you took the approach above. I'm wondering whether splitting libcrypto into 3 might be worthwhile: libcrypto-core.so - Core elements of libcrypto needed by libssl libcrypto.so - Would depend on libcrypto-core. Adds mainstream and current crypto stuff that isn't needed by libssl libcrypto-legacy.so - Would depend on libcrypto and libcrypto-core. Just the legacy algorithms. That way users who only have an interest in libssl don't have to carry around all the other stuff that libcrypto provides - only those bits they need. Apps using libcrypto directly can mostly just forget about libcrypto-legacy and just add it if they really need it. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev