------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=674
--- Comment #22 from Phil Pennock <exim-dev@???> 2009-10-19 01:30:13 ---
Re OPENSSL_NO_SHA256 -- current code within OpenSSL can use it, because current
code can assume that it's defined if SHA256 is not loaded. But it won't be
defined before the potential support was written, so if we need to work with
OpenSSL 0.9.7, which we apparently do, then we can't rely on it being present.
Yes, version numbers are clumsy, but as you note, this is a pragmatic fix, not
an ideal one. Ideally, OpenSSL would define macros asserting the availability
of functions; unavailability assertions are useless for any project depending
on their code (unless they're using 0.9.8 or later), only useful within their
own codebase.
So perhaps it needs to be:
#if (OPENSSL_VERSION_NUMBER >= 0x0090800fL) && !defined(OPENSSL_NO_SHA256)
EVP_add_digest(EVP_sha256());
#endif
How ugly.
Re SHA224 -- I think we should either be doing the minimal possible beyond
default load, explicitly for interoperability (so SHA256) or we should be
looking at my original patch, providing the openssl_load_all functionality.
That patch let you load all ciphers, if and only if you also set
tls_require_ciphers. If we're going to go beyond "just the hash algorithm
currently becoming popular", I do think that patch is the better approach.
Pragmatically, we should have openssl_load_all available and irregardless of
that, load SHA256 by default; it's not ideal, but it will reduce mailing-list
burden by making the most common desired setup the default.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
