[openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

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