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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
