Mailing List Archive: exim: dev

Exim 4.80 RC4 uploaded

Index | Next | Previous | View Threaded

phil.pennock at spodhuis

May 20, 2012, 9:55 PM

Post #1 of 17 (389 views)
Permalink

Exim 4.80 RC4 uploaded

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

There was no RC3; there are some changes since RC2 worthy of note.

There is a new option "tls_dh_max_bits" which affects TLS; with OpenSSL,
it may cause a "tls_dhparams" file to be ignored. With GnuTLS, the
number of bits GnuTLS recommends be used for Diffie-Hellman generation
will be clamped to at most this value. The default "tls_dh_max_bits" is
the current maximum allowed by the NSS security library used by Mozilla
products such as Thunderbird. This resolves a GnuTLS vs NSS
interoperability problem.

Exim will now check the configured value of "tls_require_ciphers" at
startup; what was an error that would cause Exim to fail STARTTLS will
instead cause Exim to fail to start. This exposes latent
misconfiguration and makes it clearer that something is going wrong.
This also avoids the risk of crashes while talking to a remote server,
if there are library linkage problems, reducing the chances of anything
being exploitable.

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

http://git.exim.org/exim.git/blob/exim-4_80_RC4:/doc/doc-txt/ChangeLog
http://git.exim.org/exim.git/blob/exim-4_80_RC4:/doc/doc-txt/NewStuff
http://git.exim.org/exim.git/blob/exim-4_80_RC4:/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.

Checksums below. Detached PGP signatures in .asc files are available
alongside the tarballs.

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

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

SHA256(exim-4.80_RC4.tar.bz2)= 35a9f026bbc609a05bad99f19f11372e9cd84534aad3b4420751a026ee4a320a
SHA256(exim-4.80_RC4.tar.gz)= fbc4154a7cb6763022eb79b91d4ce1d891b2c9583bd4b40407ea536c77ea68c2
SHA256(exim-html-4.80_RC4.tar.bz2)= a5eefe4a2ae04354eecfbc4848c65918b7667e4abc84ca10ed8c46ddc5a25977
SHA256(exim-html-4.80_RC4.tar.gz)= db2c641caa389e940324ca7d07d0bdc1c62a13950878deeb589e9f16aef1869e
SHA256(exim-pdf-4.80_RC4.tar.bz2)= 4af728a14aa070d4e06fb141670f789d6b34fe9f2864a854d12ce17fa31446fa
SHA256(exim-pdf-4.80_RC4.tar.gz)= b70fa8e2842102b7e280a9ea2d0083ba2ea2ca8d6f71e771ccb77f089c9246ba
SHA256(exim-postscript-4.80_RC4.tar.bz2)= 63fbeb59a6d208ffd8f8c82bbbc8e5cf31f92331d15c05762035f536fc4fcd3c
SHA256(exim-postscript-4.80_RC4.tar.gz)= b4cf268f15f70bf3945df400c3e6fd0d5d7c401329cfb169a028bbaf2f6ce171

SHA1(exim-4.80_RC4.tar.bz2)= 50424c8272312e1bd081b3adaf7e2cc5a0a5c725
SHA1(exim-4.80_RC4.tar.gz)= 214735555fda62562ecfad11c50da75dec11ebb6
SHA1(exim-html-4.80_RC4.tar.bz2)= 1ca13c68850c0043cb1031d7a8f64481b1643bfb
SHA1(exim-html-4.80_RC4.tar.gz)= 5754ec52d6338dee941f29ca09c77820c5f9b8f0
SHA1(exim-pdf-4.80_RC4.tar.bz2)= ba77cb571603fae068b47c619f82bcb912e134e8
SHA1(exim-pdf-4.80_RC4.tar.gz)= fd3f0c618549a4ff04d3e2614da5ad7afe12246a
SHA1(exim-postscript-4.80_RC4.tar.bz2)= 7406c012416d1767b85821c0fa9c6d0f1cb42745
SHA1(exim-postscript-4.80_RC4.tar.gz)= cdccb3a6bdd3502d7b620e6d70f24748281ba3cf

pdp at exim

May 20, 2012, 10:00 PM

Post #2 of 17 (383 views)
Permalink

Exim 4.80 RC4 uploaded [In reply to]

pdp at exim

May 20, 2012, 10:26 PM

Post #3 of 17 (381 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 at 01:00 -0400, Phil Pennock wrote:
> There was no RC3; there are some changes since RC2 worthy of note.

RC3: I need to learn to do a "make spec.pdf" before laying down the tag.
The OptionLists.txt could ride until the following RC or the release if
this is the last RC.

A parse error in spec.xfpt broke the docs build, and because I'd pushed
the tags, deleting would have been "hard", so I just advanced to RC4.

> Exim will now check the configured value of "tls_require_ciphers" at
> startup;

This one is half-way between "new feature" and "needed to expose that
you really need to look at tls_required_ciphers if using GnuTLS"; I
exercised Release Coordinator's prerogative in deciding to shove it in.

It may cause breakage, but really at this point I think it only "breaks"
what was already broken. We paniclog on most main section options being
broken, no need to exclude this one.

-Phil

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

doctor at doctor

May 21, 2012, 9:24 AM

Post #4 of 17 (373 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

Weird stuff to report.

I did try the 4.80_RC4 Local/Makefile and got nowhere.

copied in the 4.7X Local/Makefile and that work.

Huh?

--
Member - Liberal International This is doctor [at] nl2k Ici doctor [at] nl2k
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising!
http://www.fullyfollow.me/rootnl2k
That church which changes with the times cannot also be abiding in Christ

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

eximusers at downhill

May 21, 2012, 11:17 AM

Post #5 of 17 (384 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 Phil Pennock <pdp [at] exim> wrote:
> I have uploaded Exim 4.80 RC4 to:
> ftp://ftp.exim.org/pub/exim/exim4/test/

> There was no RC3; there are some changes since RC2 worthy of note.
[...]

I have just uploaded to Debian/experimental, packages should be
available after the next mirrror run.

cu andreas

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

jgh at wizmail

May 21, 2012, 12:04 PM

Post #6 of 17 (388 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 06:00, Phil Pennock wrote:
> I have uploaded Exim 4.80 RC4

A testsuite issue with, I'm guessing, an older GnuTLS library -
the strings coming out of gnutls_strerror() differ
on my test system vs. the expected values.

Eg:

===============f test-mainlog-munged with log/2027 failed
Line 6 of "test-mainlog-munged" does not match line 6 of "log/2027".
----------
1999-03-02 09:44:33 10HmaY-0005vi-00 TLS error on connection to ip4.ip4.ip4.ip4 [ip4.ip4.ip4.ip4] (gnutls_handshake): Error in the push function.
----------
1999-03-02 09:44:33 10HmaY-0005vi-00 TLS error on connection to ip4.ip4.ip4.ip4 [ip4.ip4.ip4.ip4] (gnutls_handshake): A TLS packet with unexpected length was received.
===============

Must I add munging to eliminate the noise or is
there a more sophisticated fix?

--
Cheers,
Jeremy

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

jgh at wizmail

May 21, 2012, 2:09 PM

Post #7 of 17 (380 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 20:04, Jeremy Harris wrote:
> On 2012-05-21 06:00, Phil Pennock wrote:
>> I have uploaded Exim 4.80 RC4

more....

GnuTLS/2025 TLS server: tls_require_ciphers
** Command 3 ("exim", starting at line 5)
** Return code 1 (expected 0)
show stdErr, show stdOut, Retry, Continue (without file comparison), or Quit? [Q] o

show stdErr, show stdOut, Retry, Continue (without file comparison), or Quit? [Q] e
2012-05-21 22:04:16 Exim configuration error:
tls_require_ciphers invalid: gnutls_priority_init(!RSA_AES_256:DES-CBC3-SHA) failed at offset 0, "!RSA_AES.." failed: The request is invalid.

(Scientific Linux 6 - a Fedora derivative)

[root [at] v6 test]# uname -r
2.6.32-220.7.1.el6.x86_64
[root [at] v6 test]# yum provides */gnutls
gnutls-devel-2.8.5-4.el6.x86_64 : Development files for the gnutls package

--
Jeremy

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

pdp at exim

May 21, 2012, 7:02 PM

Post #8 of 17 (373 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 at 22:09 +0100, Jeremy Harris wrote:
> On 2012-05-21 20:04, Jeremy Harris wrote:
> > On 2012-05-21 06:00, Phil Pennock wrote:
> >> I have uploaded Exim 4.80 RC4
>
> more....
>
> GnuTLS/2025 TLS server: tls_require_ciphers

2025 is known broken, I thought I'd commented upon it in a previous
mail. I saw this when testing before the RC cut and after a little
prodding decided to skip it.

Previously I thought that it was that we were expanding the available
cipher suites, so the previous assumptions within the more restricted
set didn't hold.

Instead, the new start-up check is revealing that the string used for
the test just is not accepted by GnuTLS as a priority string. This is
the big backwards-compatibility break.

Fortunately, I suspect that very few people ever actually set
tls_require_ciphers, so the fallout won't be too bad. But we do need to
figure out the idea behind this test so that we can properly test it in
the new world order.

-Phil

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

pdp at exim

May 21, 2012, 7:02 PM

Post #9 of 17 (372 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-21 at 10:24 -0600, The Doctor wrote:
> Weird stuff to report.
>
> I did try the 4.80_RC4 Local/Makefile and got nowhere.
>
> copied in the 4.7X Local/Makefile and that work.

There is nothing actionable in this report.

-Phil

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

aj.thew at gmail

May 22, 2012, 3:58 AM

Post #10 of 17 (362 views)
Permalink

Re: [exim] Exim 4.80 RC4 uploaded [In reply to]

On 21 May 2012 06:00, Phil Pennock <pdp [at] exim> wrote:
> I have uploaded Exim 4.80 RC4 to:
> � � � �ftp://ftp.exim.org/pub/exim/exim4/test/
>
> There was no RC3; there are some changes since RC2 worthy of note.
>
> There is a new option "tls_dh_max_bits" which affects TLS; with OpenSSL,
> it may cause a "tls_dhparams" file to be ignored. �With GnuTLS, the
> number of bits GnuTLS recommends be used for Diffie-Hellman generation
> will be clamped to at most this value. �The default "tls_dh_max_bits" is
> the current maximum allowed by the NSS security library used by Mozilla
> products such as Thunderbird. �This resolves a GnuTLS vs NSS
> interoperability problem.
>

I have a RHEL5 64bit system which requires the

CC="gcc -fgnu89-inline -std=gnu99"

fix to enable a full compile.

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)

--
A Thew

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

wbreyha at gmx

May 22, 2012, 5:18 AM

Post #11 of 17 (368 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

Phil Pennock wrote, on 21.05.2012 07:00:
> I have uploaded Exim 4.80 RC4 to:
> ftp://ftp.exim.org/pub/exim/exim4/test/

Building on CentOS 5.8 i386 fails with:
gcc expand.c
expand.c: In function �eval_op_mult�:
expand.c:3196: error: �LLONG_MIN� undeclared (first use in this function)
expand.c:3196: error: (Each undeclared identifier is reported only once
expand.c:3196: error: for each function it appears in.)
expand.c:3200: error: �LLONG_MAX� undeclared (first use in this function)
expand.c: In function �expand_string_integer�:
expand.c:6178: error: �LLONG_MAX� undeclared (first use in this function)
expand.c:6178: error: �LLONG_MIN� undeclared (first use in this function)
make[1]: *** [expand.o] Error 1
make[1]: Leaving directory `/opt/exim/src/exim-4.80_RC4/build-Linux-i386'
make: *** [all] Error 2

That's caused by /usr/include/limits.h from glibc-headers including
# ifdef __USE_ISOC99
# endif
arround definition of LLONG_MIN/MAX.

Setting
CC=gcc -std=gnu99
like A J Thew, but without quotes, fixed it.

Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha [at] gmx> | http://www.blafasel.at/
Vienna University Computer Center | Austria

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

marcin at mejor

May 22, 2012, 7:16 AM

Post #12 of 17 (362 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

W dniu 21.05.2012 07:00, Phil Pennock pisze:
> I have uploaded Exim 4.80 RC4 to:
> ftp://ftp.exim.org/pub/exim/exim4/test/

Hi all!
I've created clang static analysis[1][2] for this version of exim. I
don't know how to generate diff beetwen two analysis, as for know diff
has to be done using own eyes.
I changed options for analyzer, now they are:
$ scan-build -maxloop 15 -analyze-headers -enable-checker
security.insecureAPI.strcpy, security.insecureAPI.vfork,
security.insecureAPI.mktemp, security.insecureAPI.getpw,
security.insecureAPI.gets, security.insecureAPI.mkstemp,
security.FloatLoopCounter, security.insecureAPI.UncheckedReturn

Exim was built with:
LOOKUP_SQLITE=yes
AUTH_CRAM_MD5=yes
AUTH_CYRUS_SASL=yes
AUTH_DOVECOT=yes
AUTH_PLAINTEXT=yes
AUTH_SPA=yes
DLOPEN_LOCAL_SCAN=yes
EXPERIMENTAL_DCC=yes
EXPERIMENTAL_SPF=yes
EXPERIMENTAL_SRS=yes
HAVE_ICONV=yes
IPV6_USE_INET_PTON=yes
LOOKUP_CDB=yes
LOOKUP_DBM=yes
LOOKUP_DNSDB=yes
LOOKUP_DSEARCH=yes
LOOKUP_LDAP=yes
LOOKUP_LSEARCH=yes
LOOKUP_MYSQL=yes
LOOKUP_NISPLUS=yes
LOOKUP_NIS=yes
LOOKUP_PASSWD=yes
LOOKUP_PGSQL=yes
ROUTER_ACCEPT=yes
ROUTER_DNSLOOKUP=yes
ROUTER_IPLITERAL=yes
ROUTER_MANUALROUTE=yes
ROUTER_QUERYPROGRAM=yes
ROUTER_REDIRECT=yes
SUPPORT_DSN=yes
SUPPORT_MAILDIR=yes
SUPPORT_MAILSTORE=yes
SUPPORT_MBX=yes
SUPPORT_PAM=yes
SUPPORT_TLS=yes
SYSLOG_LOG_PID=yes
TRANSPORT_APPENDFILE=yes
TRANSPORT_AUTOREPLY=yes
TRANSPORT_LMTP=yes
TRANSPORT_PIPE=yes
TRANSPORT_SMTP=yes
USE_DB=yes
USE_GNUTLS=yes
USE_TCP_WRAPPERS=yes
WITH_CONTENT_SCAN=yes
WITH_OLD_DEMIME=yes

Regards,
Marcin

clang - at rev 157239, gentoo.

[1] - exim with gnutls:
http://mejor.pl/clang-analysis/exim-4.80_rc4-gnutls/index.html
[2] - exim with openssl:
http://mejor.pl/clang-analysis/exim-4.80_rc4-openssl/index.html

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

tlyons at ivenue

May 22, 2012, 7:23 AM

Post #13 of 17 (362 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On Tue, May 22, 2012 at 5:18 AM, Wolfgang Breyha <wbreyha [at] gmx> wrote:
> Building on CentOS 5.8 i386 fails with:
> gcc expand.c
> expand.c: In function �eval_op_mult�:
> expand.c:3196: error: �LLONG_MIN� undeclared (first use in this function)
<snip>

>
> That's caused by /usr/include/limits.h from glibc-headers including
> # �ifdef __USE_ISOC99
> # �endif
> arround definition of LLONG_MIN/MAX.
>
> Setting
> CC=gcc -std=gnu99
> like A J Thew, but without quotes, fixed it.

Since several of us now on CentOS has had to use this -std=gnu99 to
get it to compile, is there some detection we can do or just document
it in the README? Is it the version of glibc that's the issue?

...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/ ##

wbreyha at gmx

May 22, 2012, 8:50 AM

Post #14 of 17 (357 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

Todd Lyons wrote, on 22.05.2012 16:23:
> Since several of us now on CentOS has had to use this -std=gnu99 to
> get it to compile, is there some detection we can do or just document
> it in the README? Is it the version of glibc that's the issue?

The limits.h from RHEL6/CentOS6 glibc is no different. Seems that gcc runs in
gnu99 mode there.

Maybe a

#ifndef __USE_ISOC99
# undef LLONG....
# define LLONG....

in os.h-Linux?

Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha [at] gmx> | http://www.blafasel.at/
Vienna University Computer Center | Austria

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

pdp at exim

May 22, 2012, 9:22 PM

Post #15 of 17 (353 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-22 at 16:16 +0200, Marcin Mirosław wrote:
> W dniu 21.05.2012 07:00, Phil Pennock pisze:
> > I have uploaded Exim 4.80 RC4 to:
> > ftp://ftp.exim.org/pub/exim/exim4/test/
>
> Hi all!
> I've created clang static analysis[1][2] for this version of exim. I
> don't know how to generate diff beetwen two analysis, as for know diff
> has to be done using own eyes.

I don't know clang very well, but I've looked over
http://clang-analyzer.llvm.org/annotations.html and not seen anything
helpful.

Do you know of a way to teach clang that certain flags in a particular
parameter mean that the function call will not return?

When log_write()'s flags parameter includes LOG_PANIC_DIE, the call does
not return. If the analyser knew this, then some of the analysis
complaints would go away.

We can restructure some of the code and introduce a different variant
which panics and has a noreturn attribute on it, but if we can avoid
doing so then that would be helpful.

-Phil

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

jgh at wizmail

May 23, 2012, 12:40 PM

Post #16 of 17 (342 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

On 2012-05-22 16:50, Wolfgang Breyha wrote:
> Todd Lyons wrote, on 22.05.2012 16:23:
>> Since several of us now on CentOS has had to use this -std=gnu99 to
>> get it to compile, is there some detection we can do or just document
>> it in the README? Is it the version of glibc that's the issue?
>
> The limits.h from RHEL6/CentOS6 glibc is no different. Seems that gcc runs in
> gnu99 mode there.

Here on SL6, limits.h has defined two ways, one of which has the __USE_ISOC99
guard. Adding CFLAGS += -std=gnu99 seems to make no difference to
the compilation (std=c99 kills it horribly, for other reasons).

It sounds like a suggestion for GCC users to add std=gnu99 would be
useful, as a minimum. I'll do that unless someone has a better idea?

--
Cheers,
Jeremy

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

marcin at mejor

May 23, 2012, 2:57 PM

Post #17 of 17 (340 views)
Permalink

Re: Exim 4.80 RC4 uploaded [In reply to]

W dniu 23.05.2012 06:22, Phil Pennock pisze:
> I don't know clang very well, but I've looked over
> http://clang-analyzer.llvm.org/annotations.html and not seen anything
> helpful.
>
> Do you know of a way to teach clang that certain flags in a particular
> parameter mean that the function call will not return?
>
> When log_write()'s flags parameter includes LOG_PANIC_DIE, the call does
> not return. If the analyser knew this, then some of the analysis
> complaints would go away.
>
> We can restructure some of the code and introduce a different variant
> which panics and has a noreturn attribute on it, but if we can avoid
> doing so then that would be helpful.

I couldn't find information how to do it. Here is
http://clang.llvm.org/docs/UsersManual.html#analyzer_diagnositics
how to completly disable analyzer for a pice of code but it still needs
changes in code. And it isn't good solution neither.
Maybe it would be good to describe problem on clang-dev mailinglist?
Marcin

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads