[openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni openssl-users at dukhovni.org
Fri Nov 13 22:55:41 UTC 2015


On Fri, Nov 13, 2015 at 05:24:01PM -0500, Daniel Kahn Gillmor wrote:

> I'm less sympathetic in this case, since these functions have
> well-defined semantics when a cipher has been removed (or simply isn't
> present in the first place): they return NULL on error, and if code X
> doesn't handle errors properly, it's up to code X to fix that problem.

I think we can agree that link-time errors are preferrable to
run-time errors.  The latter are far less obvious to distribution
maintainers who build lots of software, but don't necessarily have
code-coverage tests for it, and don't even know what user-developed
scripts do.

> Of course, no one will catch this at compile time, or even at dynamic
> link time -- it'll get "caught" at runtime, which probably means
> codepaths that haven't been tickled maybe ever.

Yes, some code will break.  It may no longer be able to decrypt
old files, or read archived S/MIME messages.

> At any rate, it's not hard to search for uses of EVP_get_*byname [0] --
> places where those are used with hard-coded strings without error
> checking can be ferreted out and fixed, and places where they're invoked
> indirectly should probably just pass the error message upward in the
> stack, no?

Often the strings are not hard-coded, they are chosen by all kinds
of code that uses the library that wraps the EVP interface.

-- 
	Viktor.


More information about the openssl-dev mailing list