[Bug 674] New: exim can't verify sha256WithRSAEncryption signature in X. 509 certificates when linked against OpenSSL

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674
           Summary: exim can't verify sha256WithRSAEncryption signature in
                    X.509 certificates when linked against OpenSSL
           Product: Exim
           Version: 4.68
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: TLS
        AssignedTo: nigel@...
        ReportedBy: eximBugzilla@...
                CC: exim-dev@...


Created an attachment (id=236)
 --> (http://bugs.exim.org/attachment.cgi?id=236)
certs, private key for client cert

exim 4.68, linked against OpenSSL
(also tried older versions, both on Linux and FreeBSD)

configured to verify client certificates


tls_advertise_hosts = *
tls_certificate = <any server certificate>
tls_privatekey = <any private key file>

tls_try_verify_hosts = *
tls_verify_certificates = rootCaCert.pem

Root CA cert has sha256WithRSAEncryption.
The client certificate is signed by the root cert and also has a
sha256WithRSAEncryption.

Verification will fail because the signature can't be checked.

The problem is in src/tls-openssl.c, function tls_init()
exim calls OpenSSL_add_ssl_algorithms();
This function initializes sha1 but not sha256.

A simple solution/workaround is


--- tls-openssl.c.orig  2008-02-21 22:37:46.000000000 +0100
+++ tls-openssl.c       2008-02-21 22:38:12.000000000 +0100
@@ -295,6 +295,7 @@
 {
 SSL_load_error_strings();          /* basic set up */
 OpenSSL_add_ssl_algorithms();
+OpenSSL_add_all_digests();

 /* Create a context */

This solved the problem for me.

Of course, you could argue this is actually an OpenSSL issue...

I just had a look, the same issue exists in 4.69.

I attach a root cert and a client cert+key to help you track this down.

Please get back to me if you need more information.

Best regards,

   Martin


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674

Phil Pennock <exim-dev@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |exim-dev@...




--- Comment #1 from Phil Pennock <exim-dev@...>  2008-02-22 10:00:36 ---
Which version of OpenSSL is this?  ("openssl version" command)

I'm running OpenSSL 0.9.8g and the man-page for SSL_library_init() states:

       SSL_library_init() registers the available ciphers and digests.

       OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms() are
       synonyms for SSL_library_init().
...
EXAMPLES
       A typical TLS/SSL application will start with the library
       initialization, will provide readable error messages and will seed the
       PRNG.

        SSL_load_error_strings();                /* readable error messages */
        SSL_library_init();                      /* initialize library */
        actions_to_seed_PRNG();

So whilst I'm not disputing that in your version it's needed, in my version
that would appear to result in a double initialisation (perhaps harmless?) and
it would be good to track down what version dependencies there are.

Looking for the first TLS instance in today's mainlog, I see:
  X=TLSv1:DHE-RSA-AES256-SHA:256
so Exim 4.69 with OpenSSL 0.9.8g is getting the SHA256 digest function.
(FreeBSD 6.2, FWIW).

Thanks


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #2 from Phil Pennock <exim-dev@...>  2008-02-22 10:18:36 ---
No, I take back the part about it being present for me.  I misread the cipher
string.  The :256 is from Exim and is the 256 returned by SSL_CIPHER_get_bits()
and so is just repeating the 256 in AES256.

So I don't have contrary evidence, merely contrary documentation, which is a
whole different animal.  Alas.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #3 from Martin Kaiser <eximBugzilla@...>  2008-02-22 12:04:09 ---
(In reply to comment #1)

I saw your follow-up, anyway I'll add some infos for completeness.

> Which version of OpenSSL is this?  ("openssl version" command)
>
> I'm running OpenSSL 0.9.8g and the man-page for SSL_library_init() states:

I'm also running 0.9.8g.
SSL_library_init() is the same in the current 0.9.9 snapshot

It only initializes MD5, SHA-1 and DSA with SHA1.

Thinking about this, I get the impression that SHA256 should be added there.

   Martin


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

[Tony Finch]

------- 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 #4 from Tony Finch <dot@...>  2008-02-25 12:28:43 ---
On Thu, 21 Feb 2008, Martin Kaiser wrote:
>
> +OpenSSL_add_all_digests();

Does this add less secure digests as well as SHA256?
Why isn't this a bug in OpenSSL?

Tony.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #5 from Phil Pennock <exim-dev@...>  2008-08-13 08:10:35 ---
FWIW, this does not fail for me until I use tls_verify_hosts instead of
tls_try_verify_hosts.  For obvious reasons.

16291 LOG: MAIN
16291   SSL verify error: depth=1 error=certificate signature failure
cert=/C=DE/ST=Hessen/L=Frankfurt/O=GUUG FFG 2008/OU=Example CA/CN=Martin
Kaiser/emailAddress=ffg2008@...
[...]
16291 LOG: MAIN
16291   TLS error on connection from (openssl.client.net) [127.0.0.1]:50863
(SSL_accept): error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown
message digest algorithm
16291 TLS failed to start
[...]
16291 SMTP>> 554 Security failure

Looking through the source for s_server.c in OpenSSL 0.9.8h I see it calls
OpenSSL_add_all_algorithms() which adds all ciphers and all digests; that
includes password-based ciphers, according to the man-page but I've no idea if
that's likely to cause problems in a server expecting to work from a
certificate.

I guess the real question is whether or not it's bad to load all digests
(and/or ciphers) when the Exim option tls_require_ciphers is set and whether or
not we need a new tls_require_digests option (or if the ciphers option digest
field stuff is sufficient for cert verification).

If tls_require_ciphers is a saving throw, then what probably needs to happen is
that the tls_require_ciphers option should have a reasonable default set,
instead of being unset by default, and then we add a call to
OpenSSL_add_all_algorithms().

Does anyone here have any expertise in this?  If not, there are some people I
can ask for help elsewhere.

Anyone have any thoughts on what a reasonable default tls_require_ciphers would
then be?  I myself use:
tls_require_ciphers = ALL:!SSLv2:!LOW:!EXPORT:!ADH:!aNULL:!NULL:!DES:@STRENGTH
but some of that is belt&braces and perhaps disabling EXPORT ciphers isn't an
appropriate default.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

[Tony Finch]

------- 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 #6 from Tony Finch <dot@...>  2008-08-13 12:13:38 ---
On Wed, 13 Aug 2008, Phil Pennock wrote:
>
> I guess the real question is whether or not it's bad to load all digests
> (and/or ciphers) when the Exim option tls_require_ciphers is set and whether or
> not we need a new tls_require_digests option (or if the ciphers option digest
> field stuff is sufficient for cert verification).

That sounds plausible.

> If tls_require_ciphers is a saving throw, then what probably needs to happen is
> that the tls_require_ciphers option should have a reasonable default set,
> instead of being unset by default, and then we add a call to
> OpenSSL_add_all_algorithms().

No, it's not Exim's job to know that kind of detail about TLS.

> Does anyone here have any expertise in this?  If not, there are some people I
> can ask for help elsewhere.

That would be helpful.

Tony.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

[Tony Finch]

Thanks for going through those bugs, Phil.

Tony.
--
f.anthony.n.finch  <dot@...>  http://dotat.at/
ROCKALL: NORTHEASTERLY 4 OR 5, BUT NORTHWESTERLY 5 TO 7 IN SOUTH FOR A TIME.
MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #7 from Phil Pennock <exim-dev@...>  2008-08-14 02:37:20 ---
Feedback from a colleague involved in such matters; these are not his words,
but me trying to summarise an IM conversation.

There's stuff required by the TLS specs for support, and there's other
algorithms.  If it's not required by specs, it's not in the default init
(implied but not directly stated).

The cipher lists are distinct from the certificate verification;
SSL_CTX_set_cipher_list() affects only the negotiated session and has nothing
to do with identity verification on the remote end.  Anything we do here
doesn't affect ability to verify certificate signatures.

We should really be setting a cipher spec instead of accepting anything; he got
cautious about saying what should be done by applications, but the impression I
was left with was that applications doing SSL need to know enough to have
policies and set defaults.  "turn off SSL2 and export/weak ciphers, and you're
good to go" which he confirmed mapped to "ALL:!SSLv2:!LOW:!EXPORT:@STRENGTH"; I
presented what I personally set,
"ALL:!SSLv2:!LOW:!EXPORT:!ADH:!aNULL:!NULL:!DES:@STRENGTH" and got "sure.
that's a bit better" and "you might also disable EDH, which gives forward
secrecy but is also a cpu hog".

So there doesn't appear to be a good way to enable more hash types for
certificate validation without embedding knowledge of what to avoid.

If we think that SHA256 is something explicitly worth supporting for real world
production, as opposed to something someone is using in a private test-case,
then we can do:
  EVP_add_digest(EVP_sha256())

(2008-08-13 17:59:49) Phil Pennock: So, we should be running
OpenSSL_add_all_algorithms(), we should be setting
SSL_CTX_set_cipher_list() and there is not at this time a convenient
interface to affect the normal internal
SSL_CTX_set_cert_verify_callback()-controlled chain, we have to embed knowledge
of poor ciphers in the normal application-specified callback (set by
SSL_CTX_set_verify()); and really, it boils down to "you're only going to
verify signed certs anyway, so if you don't trust the CA, don't have the CA in
the list" and it shouldn't matter past that?
(2008-08-13 18:00:32) Phil Pennock: for "convenient interface" I mean something
analogous to the cipher spec list for SSL_CTX_set_cipher_list() which can be
exposed as a string to administrator configuration.

(no response yet to confirm that, but that's the impression I'm left with)


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #8 from Phil Pennock <exim-dev@...>  2008-08-14 02:46:32 ---
*sigh*  In "of poor ciphers in the normal", I mis-spoke.  Poor digest
algorithms.  Sorry.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #9 from Phil Pennock <exim-dev@...>  2008-08-14 05:49:32 ---
Created an attachment (id=261)
 --> (http://bugs.exim.org/attachment.cgi?id=261)
New global option, openssl_load_all

I think this is a reasonable compromise and sensible way forward for now,
without undermining the whole point of the exercise.

A new option, available when SUPPORT_TLS defined, "openssl_load_all".  It's a
boolean, default false.  It is a fatal error to set this true without also
defining "tls_require_ciphers".

The theory being that anyone who knows to load all algorithms knows enough to
make their own educated decision about a cipher policy but that loading all
algorithms has the risk of adding new dangerous ciphers that should not be
present and would be a security step backwards.  This avoids Exim needing to
push a cipher which can become stale and puts Exim only in the position of
having some mild protection against accidental shooting of self in foot.

I was able to use Martin's sha256 stuff successfully with this patch.


Documentation patch to come next, when I write it.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #10 from Phil Pennock <exim-dev@...>  2008-08-14 06:17:09 ---
Created an attachment (id=262)
 --> (http://bugs.exim.org/attachment.cgi?id=262)
Documentation patch

Here is the documentation for openssl-load-all.patch.

Note that as I don't have xmlto installed I can't actually verify that I've
done the right thing with all these markup tags.  I am not familiar with
docbook.  I hope that if nothing else the text is acceptable and some markup
fixups will have to be done by the committer (if the other patch is accepted).


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #11 from Martin Kaiser <eximBugzilla@...>  2008-08-14 21:02:12 ---
(In reply to comment #9)

Hi Phil,

nice to see that there's been some activity about this bug lately ;-)

> Created an attachment (id=261)
 --> (http://bugs.exim.org/attachment.cgi?id=261) [details]

> New global option, openssl_load_all
>
> I think this is a reasonable compromise and sensible way forward for now,
> without undermining the whole point of the exercise.
>
> A new option, available when SUPPORT_TLS defined, "openssl_load_all".  It's a
> boolean, default false.  It is a fatal error to set this true without also
> defining "tls_require_ciphers".
>
> The theory being that anyone who knows to load all algorithms knows enough to
> make their own educated decision about a cipher policy but that loading all
> algorithms has the risk of adding new dangerous ciphers that should not be
> present and would be a security step backwards.  This avoids Exim needing to
> push a cipher which can become stale and puts Exim only in the position of
> having some mild protection against accidental shooting of self in foot.
>
> I was able to use Martin's sha256 stuff successfully with this patch.
>

no doubt that this is going to do the trick. However, I think this is quite
complicated for an admin. Thinking about the issue again, my preferred solution
would be to just add SHA256 by a call to EVP_AddDigest(). This way, we're not
accidentially enabling weak ciphers and there's no additional complexity for
the exim administrator. I would assume that X.509 certificates with
sha256-based signature (or more exactly pkcs1 1.5 signature using sha256) will
become more and more common.

Best regards,

   Martin


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #12 from Phil Pennock <exim-dev@...>  2008-08-14 21:31:18 ---
Do you have a pointer to a standards document or policy statement from a major
CA that they're going to start using sha256 publicly?  Or Bruce Schneier saying
"Exim folks, just do it!" ;)  (The latter would be good enough for me).

Exim really should not be getting into the digests business if we can avoid it;
we're not cryptographers (AFAIK) and we're not qualified to make assertions of
what people should or should not be using, especially if that becomes dated.

Now, my personal understanding is that the weaknesses in the current standards
means that sha256 is a favoured intermediate step pending the completion of
that NIST competition to find a new digest algorithm (similarly to the AES
competition).  Our assumption is that it is true that sha256 will be actively
used in mainstream PKI then OpenSSL will be updated to load sha256 by default.

Before Exim's maintainers start going around second-guessing the maintainers of
cryptographic libraries that we depend upon, we need something firmer to verify
that, for instance, we're more pragmatic than the other maintainers; I've not
seen that verified and have no reason to believe it's true.

Until there's a major push to start actually using sha256 I believe that most
users touching it will be specialists able to configure software themselves,
knowing that they're doing, and able to set tls_require_ciphers.  I understand
that this does not mesh well with network protocols where you're talking to
systems maintained by others, but what are the options here?

Traditionally, if someone cares enough and writes a patch, then the support
spreads and the personal interests of the specialists become supported because
they care; as long as that's not to the detriment of others, no real problem
here and we'd accept patches.  However, this particular area is one of the Exim
project making assertions to others about what is or isn't safe.  Before we do
*that*, we really have to set a higher bar, IMO.  I'm sorry that you're being
held to a higher standard than is normal because of this.

Since Exim is not really an end-user application, providing knobs for
specialists to play with is fair enough.  And if there's an OpenSSL API for
loading specific named algorithms which we can expose by just passing it a
string-list, so we could have "openssl_add_algorithm sha256" in a config file,
I personally would be happy to see that in the config.  If nothing else, in the
event of a(nother) major cryptographic breakthrough acting as a forcing event
to get people using stronger hashes in x509 PKI, it's good to have the ability
to point to a configuration workaround before we bite the bullet and add the
override code as a default.  Note that here, we'd still be reacting to a policy
statement from a major CA and the only reason for adding the explicit load
would be that it lets us react faster than the lifecycle for getting a library
rolled out by all our users.  On mail-systems, I suspect that Exim updates are
tracked more closely than OpenSSL ones.

It's an ugly situation.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #13 from Phil Pennock <exim-dev@...>  2008-08-15 12:56:34 ---
You're not likely to have long to wait.  RFC 5246 is now out, specifying TLS
1.2.

----------------------------8< cut here >8------------------------------
1.2.  Major Differences from TLS 1.1

   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
   contains improved flexibility, particularly for negotiation of
   cryptographic algorithms.  The major changes are:

   -  The MD5/SHA-1 combination in the pseudorandom function (PRF) has
      been replaced with cipher-suite-specified PRFs.  All cipher suites
      in this document use P_SHA256.
[...]
----------------------------8< cut here >8------------------------------

I've just checked with someone heavily involved in the OpenSSL project and it's
likely that sha256 will be loaded by default soon.

Which then just leaves the patch I offered as a way for people to tune knobs
without being dependent upon the Exim developers.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #14 from Martin Kaiser <eximBugzilla@...>  2008-08-15 19:16:09 ---
(In reply to comment #13)

Phil,

thanks a lot for this information. No doubt it's the cleanest solution if
OpenSSL loads SHA256 by default.

Best regards,

    Martin


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #15 from Phil Pennock <exim-dev@...>  2009-06-15 03:57:24 ---
(In reply to comment #14)
> thanks a lot for this information. No doubt it's the cleanest solution if
> OpenSSL loads SHA256 by default.

I've been thinking about this some just recently; my opinion has shifted
somewhat.  I still think that the patch I previously provided is the best
solution.

However, openssl-1.0.0-beta2 is out and it still does not enable SHA-256 by
default, even though it's in standards-tracks for default usage, as noted
above.  More and more, I'm seeing real world usage shift towards sha-256 away
from SHA-1 or even MD5.

Exim *shouldn't* be getting involved in policy and loading SHA-256 manually,
but I think that pragmatically we're going to have to.

Tony, Nigel, any thoughts on this?


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #16 from Phil Pennock <exim-dev@...>  2009-06-16 00:19:44 ---
The OpenSSL developers have a different view of abstraction and where the
responsibility boundaries lay.  I asked on openssl-dev about this issue,
referencing this bug, and they're of the opinion that Exim needs someone who
keeps up-to-date on algorithm security weaknesses if Exim is to use OpenSSL.

See this thread (multiple web archives, pick your poison):

http://markmail.org/search/?q=list:org.openssl.openssl-dev#query:list%3Aorg.openssl.openssl-dev+page:2+mid:7yosrfphbuk2giik+state:results

http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/e4b15ce3abd4f1e8#

http://marc.info/?l=openssl-dev&m=124503853216248&w=2

http://www.mail-archive.com/openssl-dev@.../msg26021.html

(Six mails in thread at time of my updating this bug)

So, bite the bullet and enable EVP_sha256 by default, manually, or add my
current patch, or both, or neither or ...

With the current round of advances in breaks on SHA1, I suspect we really need
to get SHA-256 support into Exim 4.70, one way or another, before there's a
pre-image attack.  But I'm not a cryptanalyst.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=674

Tom Kistner <tom@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tom@...
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #17 from Tom Kistner <tom@...>  2009-10-16 09:35:39 ---
(In reply to comment #7)

> If we think that SHA256 is something explicitly worth supporting for real world
> production, as opposed to something someone is using in a private test-case,
> then we can do:
>   EVP_add_digest(EVP_sha256())

Been there, done that.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #18 from Phil Pennock <exim-dev@...>  2009-10-16 12:23:40 ---
Created an attachment (id=330)
 --> (http://bugs.exim.org/attachment.cgi?id=330)
Make SHA256 loading conditional upon OpenSSL >= 0.9.8

Reports of link failure on exim-users because EVP_sha256() wasn't available.

OpenSSL "CHANGES" file:
 Changes between 0.9.7h and 0.9.8  [05 Jul 2005]
[...]
  *) New FIPS 180-2 algorithms, SHA-224/-256/-384/-512 are implemented.
     [Andy Polyakov and a number of other people]

So #ifdef guard that 0.9.8 or more recent.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##