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.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
