Why not offer another set of get_XYZ_byname() which resticts the caller to socially acceptable algorithms. Or allows the opposite, it really doesn't matter but restricted being the newer API breaks less code by default.
Give it the same call syntax and it's simply an #ifdef in the OpenSSL headers for anyone who wants to spend hours working out why their code doesn't work any more. i.e. EVP_get_digestbyname() becomes EVP_get_digestbyname_r(), and if anyone actually wants only the restricted set from say a Linux distro. they can #define EVP_get_digestbyname(a) EVP_get_digestbyname_r(a) At the crypto library level this is just maths and it really doesn't make any sense to try and enforce policy at this point. I can understand the maintenance issues, but C code really isn't a problem and dropping algorithms from the sources here simply makes more work for other people elsewhere. Peter From: Viktor Dukhovni <openssl-us...@dukhovni.org> To: openssl-dev@openssl.org Date: 17/11/2015 10:02 Subject: Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Sent by: "openssl-dev" <openssl-dev-boun...@openssl.org> 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. 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. At this time, with the resources at our disposal, I think it makes more sense to take a more gradual approach and just drop the assembly support. > 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). I like the idea, but don't see a manageable implementation... > Whether this is the right thing to do in the 1.1.0 timeframe is another > consideration though. Viktor's arguments are quite convincing. The timeline is a concern. We're fairly far into the 1.1.0 development cycle (alphas and betas soon), and this is a major change. I think major changes like removing the ciphers or a whole new optional library should wait for a better opportunity. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev