Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: dev

Exim 4.80 RC2 uploaded

 

 

exim dev RSS feed   Index | Next | Previous | View Threaded


pdp at exim

May 19, 2012, 12:50 AM

Post #1 of 14 (505 views)
Permalink
Exim 4.80 RC2 uploaded

I have uploaded Exim 4.80 RC2 to:
ftp://ftp.exim.org/pub/exim/exim4/test/

The changes since RC1 are minor: the new SPF record support in dnsdb now
defaults to joining strings in the way dictated by the SPF
specification, instead of matching the TXT defaults; some header
corruption in the EXPERIMENTAL_DCC support has been fixed (and said
support has been documented in experimental-spec.txt -- it's not new
with 4.80, was just under-documented); some issues highlighted by clang
static analysis have been resolved; the test suite has been fixed after
I forgot to update the OpenSSL tests when I generated new test
certificates to replace the old MD5 ones.

It's worth re-emphasising the most significant non-backwards-compatible
change of this release: GnuTLS no longer supports MD5 in certificates.
If you still have such ancient beasts around, you're very overdue for
fixing that! Practical real-world attacks against MD5-based
certificates have been demonstrated, undermining the PKI trust model.
If your certificates are self-signed, generate new ones. If they are
from a Certificate Authority, a re-issue using a current CA cert should
be free (part of the price paid for the original cert and the ongoing
service associated with it). If not, switch to a CA who care about
working with you for your security.

The ChangeLog/NewStuff/README.UPDATING can be reviewed at:

http://git.exim.org/exim.git/blob/exim-4_80_RC2:/doc/doc-txt/ChangeLog
http://git.exim.org/exim.git/blob/exim-4_80_RC2:/doc/doc-txt/NewStuff
http://git.exim.org/exim.git/blob/exim-4_80_RC2:/src/README.UPDATING

The files are signed with the PGP key 0x3903637F, which has a uid
"Phil Pennock <pdp [at] exim>". Please use your own discretion in
assessing what trust paths you might have to this uid.

Please report issues in reply to this email, on exim-users.

Thank you for your testing and feedback,
-Phil Pennock, pp The Exim Maintainers.


tlyons at ivenue

May 19, 2012, 8:55 AM

Post #2 of 14 (486 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

Posted in Rich Text so that gmail client wouldn't line-wrap my pastes below.

On Sat, May 19, 2012 at 12:50 AM, Phil Pennock <pdp [at] exim> wrote:
> I have uploaded Exim 4.80 RC2 to:
> Please report issues in reply to this email, on exim-users.

Current master builds just fine on my Ubuntu machines (11.04 and 12.04).
Building RC2 on CentOS 5.x, compiling exim.c is failing with this:

exim.c: In function ‘regex_must_compile’:
exim.c:86: warning: dereferencing type-punned pointer will break
strict-aliasing rules
exim.c: In function ‘usr1_handler’:
exim.c:215: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
exim.c: In function ‘show_whats_supported’:
exim.c:1007: warning: implicit declaration of function ‘STRINGIFY’
exim.c:1007: error: expected ‘)’ before string constant
exim.c:1007: warning: format ‘%s’ expects type ‘char *’, but argument 6 has
type ‘int’
exim.c:1007: warning: too few arguments for format
exim.c: In function ‘main’:
exim.c:2417: warning: zero-length printf format string
exim.c:3788: warning: dereferencing type-punned pointer will break
strict-aliasing rules
exim.c:4372: warning: field precision should have type ‘int’, but argument
4 has type ‘long int’
exim.c:3718: warning: ignoring return value of ‘getcwd’, declared with
attribute warn_unused_result
exim.c:3762: warning: ignoring return value of ‘chdir’, declared with
attribute warn_unused_result
exim.c:5243: warning: ignoring return value of ‘chdir’, declared with
attribute warn_unused_result

The relevant lines are:
1007 fprintf(f, "Library version: PCRE: Compile: %d.%d%s\n"
1008 " Runtime: %s\n",
1009 PCRE_MAJOR, PCRE_MINOR,
1010 /* PRE_PRERELEASE is either defined and empty or a string.
1011 * unless its an ancient version of PCRE in which case it
1012 * is not defined */
1013 #ifdef PCRE_PRERELEASE
1014 # define STRINGIFY(x) #x
1015 STRINGIFY(PCRE_PRERELEASE) "",
1016 # undef STRINGIFY
1017 #else
1018 "",
1019 #endif
1020 pcre_version());

It looks fine to me, but the #define for some reason is not occurring. Can
you spot anything wrong with this?

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

May 19, 2012, 3:01 PM

Post #3 of 14 (479 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 at 08:55 -0700, Todd Lyons wrote:
> Current master builds just fine on my Ubuntu machines (11.04 and 12.04).
> Building RC2 on CentOS 5.x, compiling exim.c is failing with this:

> exim.c: In function ‘show_whats_supported’:
> exim.c:1007: warning: implicit declaration of function ‘STRINGIFY’
> exim.c:1007: error: expected ‘)’ before string constant
> exim.c:1007: warning: format ‘%s’ expects type ‘char *’, but argument 6 has
> type ‘int’
> exim.c:1007: warning: too few arguments for format

> The relevant lines are:
> 1007 fprintf(f, "Library version: PCRE: Compile: %d.%d%s\n"
> 1008 " Runtime: %s\n",
> 1009 PCRE_MAJOR, PCRE_MINOR,
> 1010 /* PRE_PRERELEASE is either defined and empty or a string.
> 1011 * unless its an ancient version of PCRE in which case it
> 1012 * is not defined */
> 1013 #ifdef PCRE_PRERELEASE
> 1014 # define STRINGIFY(x) #x
> 1015 STRINGIFY(PCRE_PRERELEASE) "",
> 1016 # undef STRINGIFY
> 1017 #else
> 1018 "",
> 1019 #endif
> 1020 pcre_version());
>
> It looks fine to me, but the #define for some reason is not occurring. Can
> you spot anything wrong with this?

*sigh* The very first change after the 4.77 release, because of problems
folks had with PCRE_PRERELEASE in that.

There's one mistake in it for sure: "PCRE_PRERELEASE" is being inserted
as a literal string. Doh. I've looked over that output many times and
just assumed I had a prerelease of PCRE installed.

I've rewritten the layout to move the #ifdef outside the function
definition, which *should* have absolutely no impact upon matters, but
maybe it does.

Does the attached patch fix this for you?

-Phil
Attachments: exim-pcre.patch (1.07 KB)


jgh at wizmail

May 19, 2012, 3:28 PM

Post #4 of 14 (483 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 20:32, Jeremy Harris wrote:
> On 2012-05-19 08:50, Phil Pennock wrote:
> [RC2 announcement]

... and more testsuite fun with GnuTLS (really, this time).
Seems my test system runs GnuTLS1.1 - which wasn't allowed
for by the suite. I'm leaning towards:

diff --git a/test/runtest b/test/runtest
index b8adb9a..45641f9 100755
--- a/test/runtest
+++ b/test/runtest
@@ -499,13 +499,15 @@ RESET_AFTER_EXTRA_LINE_READ:
# TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128
#
# X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256
+ # X=TLS1.2:RSA_AES_256_CBC_SHA1:256
+ # X=TLS1.1:RSA_AES_256_CBC_SHA1:256
# X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256
# and as stand-alone cipher:
# DHE-RSA-AES256-SHA256
# DHE-RSA-AES256-SHA
# picking latter as canonical simply because regex easier that way.
s/\bDHE_RSA_AES_128_CBC_SHA1:128/RSA_AES_256_CBC_SHA1:256/g;
- s/X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256/X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256/g;
+ s/TLS1.[012]:(DHE_)?RSA_AES_256_CBC_SHA(1|256):256/TLS1.x:xxxxRSA_AES_256_CBC_SHAnnn:256/g;
s/\bDHE-RSA-AES256-SHA256\b/DHE-RSA-AES256-SHA/g;


.... plus a rash of resulting testcase output changes. But I've not run
an OpenSSL build past it yet.

--
Cheers,
Jeremy


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


pdp at exim

May 19, 2012, 3:34 PM

Post #5 of 14 (478 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 at 23:28 +0100, Jeremy Harris wrote:
> On 2012-05-19 20:32, Jeremy Harris wrote:
> > On 2012-05-19 08:50, Phil Pennock wrote:
> > [RC2 announcement]
>
> ... and more testsuite fun with GnuTLS (really, this time).
> Seems my test system runs GnuTLS1.1 - which wasn't allowed
> for by the suite. I'm leaning towards:

I think you mean a version of GnuTLS which only supports TLS1.1, not
TLS1.2, rather than GnuTLS1.1.

> - s/X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256/X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256/g;
> + s/TLS1.[012]:(DHE_)?RSA_AES_256_CBC_SHA(1|256):256/TLS1.x:xxxxRSA_AES_256_CBC_SHAnnn:256/g;
> s/\bDHE-RSA-AES256-SHA256\b/DHE-RSA-AES256-SHA/g;

> .... plus a rash of resulting testcase output changes. But I've not run
> an OpenSSL build past it yet.

Is it necessary to drop the X= ? There were other instances where this
was needed?

Either normalise to the same string as before and avoid the need for
changes beyond runtest, or we should fix all of the cipher
normalisations to make it clear they're normalised, as you did, not just
this one. *sigh*

-Phil

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


jgh at wizmail

May 19, 2012, 3:43 PM

Post #6 of 14 (477 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 23:34, Phil Pennock wrote:
> On 2012-05-19 at 23:28 +0100, Jeremy Harris wrote:
>> - s/X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256/X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256/g;
>> + s/TLS1.[012]:(DHE_)?RSA_AES_256_CBC_SHA(1|256):256/TLS1.x:xxxxRSA_AES_256_CBC_SHAnnn:256/g;
[...]
> Is it necessary to drop the X= ? There were other instances where this
> was needed?

Yes, the same canonicalisation is needed for a (Received ?) header.
--
Jeremy


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


pdp at exim

May 19, 2012, 4:19 PM

Post #7 of 14 (479 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 at 23:43 +0100, Jeremy Harris wrote:
> On 2012-05-19 23:34, Phil Pennock wrote:
> > On 2012-05-19 at 23:28 +0100, Jeremy Harris wrote:
> >> - s/X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256/X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256/g;
> >> + s/TLS1.[012]:(DHE_)?RSA_AES_256_CBC_SHA(1|256):256/TLS1.x:xxxxRSA_AES_256_CBC_SHAnnn:256/g;
> [...]
> > Is it necessary to drop the X= ? There were other instances where this
> > was needed?
>
> Yes, the same canonicalisation is needed for a (Received ?) header.

*sigh* Well, the text suite is not part of the release, merely run for
the release, so feel free to make whatever changes you think best here.
As long as it still runs on my GnuTLS 2.12.x and 2.10.x test boxes I'll
be happy.

-Phil

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


jgh at wizmail

May 19, 2012, 5:18 PM

Post #8 of 14 (478 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-20 00:19, Phil Pennock wrote:
> On 2012-05-19 at 23:43 +0100, Jeremy Harris wrote:
>> On 2012-05-19 23:34, Phil Pennock wrote:
>>> On 2012-05-19 at 23:28 +0100, Jeremy Harris wrote:
>>>> - s/X=TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256/X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256/g;
>>>> + s/TLS1.[012]:(DHE_)?RSA_AES_256_CBC_SHA(1|256):256/TLS1.x:xxxxRSA_AES_256_CBC_SHAnnn:256/g;
>> [...]
>>> Is it necessary to drop the X= ? There were other instances where this
>>> was needed?
>>
>> Yes, the same canonicalisation is needed for a (Received ?) header.
>
> *sigh* Well, the text suite is not part of the release, merely run for
> the release, so feel free to make whatever changes you think best here.
> As long as it still runs on my GnuTLS 2.12.x and 2.10.x test boxes I'll
> be happy.

Pushed that; would you like to give it a whirl?
--
Jeremy

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


pdp at exim

May 19, 2012, 7:24 PM

Post #9 of 14 (476 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-20 at 01:18 +0100, Jeremy Harris wrote:
> On 2012-05-20 00:19, Phil Pennock wrote:
> > *sigh* Well, the text suite is not part of the release, merely run for
> > the release, so feel free to make whatever changes you think best here.
> > As long as it still runs on my GnuTLS 2.12.x and 2.10.x test boxes I'll
> > be happy.
>
> Pushed that; would you like to give it a whirl?

Pushed update for more stuff my GnuTLS install caught.

I omitted 2025 because this one needs looking at carefully; hrm I think
I mentioned this already but not seeing it in list archive.

2025 makes assumptions about available ciphers and what disabling
certain ones does for deliverability. It needs further examination.
But not now -- it's a test flaw, not an Exim binary flaw.

-Phil

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


pdp at exim

May 20, 2012, 12:46 AM

Post #10 of 14 (468 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 at 18:21 -0500, René Berber wrote:
> Building on Linux ( 2.6.12 ), with gcc 4.5.3 :

Which version of glibc ? Which distribution of Linux?

A number of the maintainers use Linux distributions, of various
flavours, so this is a little surprising. I'm fairly sure that the
developer who added the code causing your issues uses a Linux
distribution.

> Those constants are declared in limits.h, which is included by exim.h,
> but it (limits.h) has a guard which doesn't seem to be set by default:
>
> > # ifdef __USE_ISOC99
> >
> > /* Minimum and maximum values a `signed long long int' can hold. */
> > # define LLONG_MAX 9223372036854775807LL
> > # define LLONG_MIN (-LLONG_MAX - 1LL)
>
> Using make CC="gcc -std=gnu99", or with -std=c99, does not solve the
> problem, in fact nothing can be compiled.
>
> This didn't happen before (4.77, ...)

According to this post:
http://sources.redhat.com/ml/libc-alpha/2000-07/msg00067.html
and then this follow-up from Ulrich Drepper:
http://sources.redhat.com/ml/libc-alpha/2000-07/msg00074.html
this appears to have been fixed in <features.h> in 2000.

If you edit OS/os.h-Linux to add:
#include <features.h>
at the top, does that fix the problem? And if so, does it require
-std=gnu99 (or invocation as CC=c99) to fix it, or is it generically
fixed?

Does a Linux user know if features.h is specific to glibc or do other
Linux libc provide their own versions?

I'd have thought that other headers which depend upon these macros would
be pulling in <features.h> themselves, to get the right defines for the
compiler invocation.

-Phil

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


tlyons at ivenue

May 20, 2012, 8:55 AM

Post #11 of 14 (468 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On Sat, May 19, 2012 at 3:01 PM, Phil Pennock <pdp [at] exim> wrote:
> I've rewritten the layout to move the #ifdef outside the function
> definition, which *should* have absolutely no impact upon matters, but
> maybe it does.
> Does the attached patch fix this for you?

Yes it does. Thanks Phil. I see it already made it into master, you
were very productive last night :-)

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding

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


jgh at wizmail

May 20, 2012, 10:10 AM

Post #12 of 14 (472 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-19 08:50, Phil Pennock wrote:
> I have uploaded Exim 4.80 RC2

What's the deal with (GnuTLS) tls_channelbinding_b64 ?
The comment says "available for use for authenticators" -
is this a documented interface?

--
Cheers,
Jeremy

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


pdp at exim

May 20, 2012, 4:09 PM

Post #13 of 14 (471 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-20 at 08:55 -0700, Todd Lyons wrote:
> On Sat, May 19, 2012 at 3:01 PM, Phil Pennock <pdp [at] exim> wrote:
> > I've rewritten the layout to move the #ifdef outside the function
> > definition, which *should* have absolutely no impact upon matters, but
> > maybe it does.
> > Does the attached patch fix this for you?
>
> Yes it does. Thanks Phil. I see it already made it into master, you
> were very productive last night :-)

I declare the previous problem to be a compiler bug, barring someone
telling me otherwise citing text which permits the compiler to not treat
the stream as though it had first been passed through cpp, so that the
function arguments all already existed.

Well, the code is a little clearer in the new layout, so we're better
off anyway.

-Phil

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


pdp at exim

May 20, 2012, 4:12 PM

Post #14 of 14 (467 views)
Permalink
Re: [exim] Exim 4.80 RC2 uploaded [In reply to]

On 2012-05-20 at 18:10 +0100, Jeremy Harris wrote:
> On 2012-05-19 08:50, Phil Pennock wrote:
> > I have uploaded Exim 4.80 RC2
>
> What's the deal with (GnuTLS) tls_channelbinding_b64 ?
> The comment says "available for use for authenticators" -
> is this a documented interface?

See the GSASL code and the Exim Spec docs for it,
"server_channelbinding" option, which describes the concept and how to
turn it on.

At the moment, it's an untested code path. :/

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

exim dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.