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

Hubert Kario hkario at redhat.com
Wed Nov 18 13:39:15 UTC 2015


On Tuesday 17 November 2015 00:01:09 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.
> 
> 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.

how about having a runtime registry of supported algorithms, and having 
the libcrypto-legacy.so simply add algorithms to this list at load?

or is this mechanism not supported by some environments supported by 
openssl?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151118/1ed5aece/attachment.sig>


More information about the openssl-dev mailing list