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

Mailing List Archive: exim: dev

Exim 4.80 RC1 uploaded

 

 

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


pdp at exim

May 17, 2012, 8:55 PM

Post #1 of 9 (292 views)
Permalink
Exim 4.80 RC1 uploaded

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

This release contains a number of backwards-incompatible changes, for
both OpenSSL and GnuTLS, in the name of security (about the only reason
we normally accept for being backwards incompatible). Please read over
README.UPDATING carefully! We have jumped from 4.77 to 4.80 for this
reason.

This is the first release of Exim to support OpenSSL 1.0.1+. This
release of Exim abandons maintaining hard-coded lists of ciphers for
GnuTLS in favour of honouring GnuTLS library policy, so MD5-based
certificates will no longer work and are not supported. The GnuTLS
support has been re-written and there is the possibility of bugs.

When building, please do not just recycle your previous Local/Makefile;
there are a number of new possibilities in this release which may make
your life easier, as support for using pkg-config to query CFLAGS/LIBS
for various pieces of software has been added.

Please join me in welcoming Jeremy Harris and Todd Lyons to the Exim
Maintainers team.

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

http://git.exim.org/exim.git/blob/exim-4_80_RC1:/doc/doc-txt/ChangeLog
http://git.exim.org/exim.git/blob/exim-4_80_RC1:/doc/doc-txt/NewStuff
http://git.exim.org/exim.git/blob/exim-4_80_RC1:/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_RC1.tar.bz2)= c2b67b6baea743fc73dcf9d2e298d1eef9a79f2172958fba8fd9b3025c328bba
SHA256(exim-4.80_RC1.tar.gz)= c5a4d1402cf7eff4b4b9ced3fcee8d195f0ff1f335d13c68d58206f4f72215b9
SHA256(exim-html-4.80_RC1.tar.bz2)= fb1189bd1a053e06390d6cee3ad5bd6b508a806c0d143c4a9fc70822605d63ec
SHA256(exim-html-4.80_RC1.tar.gz)= 45fe3b2f3d6f431b010b9c665cd5bdfdd8388f08819d814ecf70b179eccccdc2
SHA256(exim-pdf-4.80_RC1.tar.bz2)= 343599159461b47156d613041cb62afb549f6286f320f9cf62eb856dd95811bc
SHA256(exim-pdf-4.80_RC1.tar.gz)= 1eb6afdfa5fd35d4130e6d305baa285d03007e456e4e4e5baf884c7608ddc287
SHA256(exim-postscript-4.80_RC1.tar.bz2)= 7867c6aba62fbeae46342bc40f384f5abaee8fb2553ceb0a7c25a1ff68b7226b
SHA256(exim-postscript-4.80_RC1.tar.gz)= c7a6a92e4f74e9afad7f702ed703d6b19a285e814d77090a2d02d21fb2b0ca4c

SHA1(exim-4.80_RC1.tar.bz2)= eb92b4b220ec5c0161d6c90503f3d0b0aea9f1f3
SHA1(exim-4.80_RC1.tar.gz)= 53f9add7baf2bf5361695cf2ff6f75e2a24f61c9
SHA1(exim-html-4.80_RC1.tar.bz2)= 0bb5a391fb22d606edf8f16263bdc45426c8ab89
SHA1(exim-html-4.80_RC1.tar.gz)= a0baf96dd903dd4e1a1c86da465b70e633009991
SHA1(exim-pdf-4.80_RC1.tar.bz2)= 961151a4fefc84b6e76ee1fceac54a0c321fe2c4
SHA1(exim-pdf-4.80_RC1.tar.gz)= 858711456ce822d9cc4464b01f419bcbe8daa2e6
SHA1(exim-postscript-4.80_RC1.tar.bz2)= 924f9cece857057e75a23e1e8d556f25ab99a353
SHA1(exim-postscript-4.80_RC1.tar.gz)= 7283d5c762264e00e6102265a8f1eaf65048c0b6


eximusers at downhill

May 18, 2012, 11:27 AM

Post #2 of 9 (286 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

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

> This release contains a number of backwards-incompatible changes, for
> both OpenSSL and GnuTLS, in the name of security (about the only reason
> we normally accept for being backwards incompatible). Please read over
> README.UPDATING carefully! We have jumped from 4.77 to 4.80 for this
> reason.
[...]

I get a strange error when building with -Werror=format-security:
---------------------
gcc -o em_main.o -c -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -Wall -fvisibility=hidden -I. -I../exim_monitor -I/usr/X11R6/include \
../exim_monitor/`echo em_main.o | sed 's/o$/c/'`
../exim_monitor/em_main.c: In function 'numlock_modifiers':
../exim_monitor/em_main.c:576:5: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
../exim_monitor/em_main.c: In function 'main':
../exim_monitor/em_main.c:659:3: error: format not a string literal and no format arguments [-Werror=format-security]
cc1: some warnings being treated as errors
make[2]: *** [em_main.o] Error 1
---------------------

which corresponds to
/* Do *not* use "%s" here, we need the %D datestamp in the log_file to
be expanded! */
(void)string_format(log_file_open, sizeof(log_file_open), CS log_file);

What's really strange is that em_main.c has not changed (except for
adding a comment), and 4.77 continues to builds with same flags and
compiler.

cu andreas

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


jgh at wizmail

May 18, 2012, 12:23 PM

Post #3 of 9 (288 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-18 04:55, Phil Pennock wrote:
[4.80 RC1 announcement]

I'm getting a bunch of testsuite GnuTLS expected-log output differences
which look to be due to use of a newer certificate. Example:

OpenSSL/2100 TLS client: TLS setup fails - retry in clear
===============f test-mainlog-munged with log/2100 failed
Line 3 of "test-mainlog-munged" does not match line 3 of "log/2100".
----------
1999-03-02 09:44:33 10HmaX-0005vi-00 SSL verify error: depth=0 error=self signed certificate cert=/C=UK/O=The Exim Maintainers/OU=Test Suite/CN=Phil Pennock
----------
1999-03-02 09:44:33 10HmaX-0005vi-00 SSL verify error: depth=0 error=self signed certificate cert=/C=UK/L=Cambridge/O=University of Cambridge/OU=Computing Service/CN=Philip Hazel
===============
1 difference found.
"test-mainlog-munged" contains 14 lines; "log/2100" contains 14 lines.


--
Cheers,
Jeremy

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


pdp at exim

May 18, 2012, 1:08 PM

Post #4 of 9 (287 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-18 at 20:23 +0100, Jeremy Harris wrote:
> On 2012-05-18 04:55, Phil Pennock wrote:
> [4.80 RC1 announcement]
>
> I'm getting a bunch of testsuite GnuTLS expected-log output differences
> which look to be due to use of a newer certificate. Example:

I blinked because I thought I caught all of those, but now I see that
although you wrote GnuTLS, you mean OpenSSL.

Indeed, I should have gone back through the test-suite with an OpenSSL
build, updating the stuff for the new certs. I'll do that now, thanks.

FWIW, we got new certs to get rid of MD5 which caused GnuTLS validation
failures; while I was at it, I went for "The Exim Maintainers" as an
org, instead of Cambridge, and pointed at myself as the victim for TLS
questions. ;)

-Phil

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


jgh at wizmail

May 18, 2012, 5:00 PM

Post #5 of 9 (287 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-18 21:08, Phil Pennock wrote:
> I blinked because I thought I caught all of those, but now I see that
> although you wrote GnuTLS, you mean OpenSSL.

You'd think I'd have learned which is which by now!
--
Jeremy

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


eximusers at downhill

May 19, 2012, 7:26 AM

Post #6 of 9 (287 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-18 Andreas Metzler <eximusers [at] downhill> wrote:
> On 2012-05-18 Phil Pennock <pdp [at] exim> wrote:
> > I have uploaded Exim 4.80 RC1 to:
[...]

> I get a strange error when building with -Werror=format-security:
> ---------------------
> gcc -o em_main.o -c -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -Wall -fvisibility=hidden -I. -I../exim_monitor -I/usr/X11R6/include \
> ../exim_monitor/`echo em_main.o | sed 's/o$/c/'`
> ../exim_monitor/em_main.c: In function 'numlock_modifiers':
> ../exim_monitor/em_main.c:576:5: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
> ../exim_monitor/em_main.c: In function 'main':
> ../exim_monitor/em_main.c:659:3: error: format not a string literal and no format arguments [-Werror=format-security]
> cc1: some warnings being treated as errors
> make[2]: *** [em_main.o] Error 1
> ---------------------

> which corresponds to
> /* Do *not* use "%s" here, we need the %D datestamp in the log_file to
> be expanded! */
> (void)string_format(log_file_open, sizeof(log_file_open), CS log_file);
[...]

Hello,

Reverting a part of e0df1c8324f0e0c4112302fa473cff6a6110a044 makes the
problem unreproducible:

--- exim4-4.80~rc2.orig/src/functions.h
+++ exim4-4.80~rc2/src/functions.h
@@ -325,7 +325,7 @@ extern uschar *string_copy_malloc(uschar
extern uschar *string_copylc(uschar *);
extern uschar *string_copynlc(uschar *, int);
extern uschar *string_dequote(uschar **);
-extern BOOL string_format(uschar *, int, const char *, ...) PRINTF_FUNCTION(3,4);
+extern BOOL string_format(uschar *, int, const char *, ...);
extern uschar *string_format_size(int, uschar *);
extern int string_interpret_escape(uschar **);
extern int string_is_ip_address(uschar *, int *);


What also makes exim compile is reverting this part of
c6e95d22d77f480804ddb5c505891206b427dfb1 (which was a partial revert
of abovementioned e0df1c8324f0e0c4112302fa473cff6a6110a044):

--- exim4-4.80~rc2.orig/exim_monitor/em_main.c
+++ exim4-4.80~rc2/exim_monitor/em_main.c
@@ -656,7 +656,7 @@ if (log_file[0] != 0)
{
/* Do *not* use "%s" here, we need the %D datestamp in the log_file to
be expanded! */
- (void)string_format(log_file_open, sizeof(log_file_open), CS log_file);
+ (void)string_format(log_file_open, sizeof(log_file_open), "%s", CS log_file);
log_datestamping = string_datestamp_offset >= 0;

cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

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


pdp at exim

May 19, 2012, 2:36 PM

Post #7 of 9 (278 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-19 at 16:26 +0200, Andreas Metzler wrote:
> On 2012-05-18 Andreas Metzler <eximusers [at] downhill> wrote:
> > On 2012-05-18 Phil Pennock <pdp [at] exim> wrote:
> > > I have uploaded Exim 4.80 RC1 to:
> [...]
>
> > I get a strange error when building with -Werror=format-security:

Right, because we're using a format check for something which isn't
quite what the check's creators expected.

The __attribute__((format(printf,A,B))) stuff is generally more useful
than not, but Exim is not actually using libc printf, but its own
string_printf(). One of the differences is that string_printf() treats
%D as special, not consuming any arguments.

If you're going to build with -Werror=format-security then you need to
#define PRINTF_FUNCTION(A,B) to /**/ in mytypes.h, which will also shut
up a bunch of other warnings. The PRINTF_FUNCTION() usage has caught a
number of small issues and been generally useful, but it's not a perfect
match. If there were a pragma to define a new format and register what
each escape expects, as a type, and declare that some do not consume
arguments, we could use that and there would be no mismatches.

> > which corresponds to
> > /* Do *not* use "%s" here, we need the %D datestamp in the log_file to
> > be expanded! */
> > (void)string_format(log_file_open, sizeof(log_file_open), CS log_file);
> [...]
>
> Hello,
>
> Reverting a part of e0df1c8324f0e0c4112302fa473cff6a6110a044 makes the
> problem unreproducible:

Right, SuSE folks supplied a patch because we weren't using
PRINTF_FUNCTION() consistently, as I'd originally only applied it to
those places where it did not trigger spurious warnings.

> What also makes exim compile is reverting this part of
> c6e95d22d77f480804ddb5c505891206b427dfb1 (which was a partial revert
> of abovementioned e0df1c8324f0e0c4112302fa473cff6a6110a044):

If you do this, then you break cases of LOG_FILE_PATH containing %D.

I think, realistically, people are going to turn on -Wformat=security
and we need to accept that and remove the safety-checks instead.
They're useful to the developers, in figuring out where there *might* be
issues, but there's so many false positive warnings, and this, that it
is not tenable for a release.

For now, can you please build without -Wformat=security and see if it
works?

-Phil

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


eximusers at downhill

May 20, 2012, 9:24 AM

Post #8 of 9 (272 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-19 Phil Pennock <pdp [at] exim> wrote:
> On 2012-05-19 at 16:26 +0200, Andreas Metzler wrote:
[...]
> If you're going to build with -Werror=format-security then you need to
> #define PRINTF_FUNCTION(A,B) to /**/ in mytypes.h, which will also shut
> up a bunch of other warnings. The PRINTF_FUNCTION() usage has caught a
> number of small issues and been generally useful, but it's not a perfect
> match. If there were a pragma to define a new format and register what
> each escape expects, as a type, and declare that some do not consume
> arguments, we could use that and there would be no mismatches.
[...]
> I think, realistically, people are going to turn on -Wformat=security
> and we need to accept that and remove the safety-checks instead.
> They're useful to the developers, in figuring out where there *might* be
> issues, but there's so many false positive warnings, and this, that it
> is not tenable for a release.

> For now, can you please build without -Wformat=security and see if it
> works?

FWIW I have just uploaded to Debian/experimental to check for
build-errors. In a first try we are building with -Wformat=security
and

--- exim4-4.80~rc2.orig/src/functions.h
+++ exim4-4.80~rc2/src/functions.h
@@ -325,7 +325,7 @@ extern uschar *string_copy_malloc(uschar
extern uschar *string_copylc(uschar *);
extern uschar *string_copynlc(uschar *, int);
extern uschar *string_dequote(uschar **);
-extern BOOL string_format(uschar *, int, const char *, ...) PRINTF_FUNCTION(3,4);
+extern BOOL string_format(uschar *, int, const char *, ...);

as this has worked for me. ;-)

cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--
## 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:05 PM

Post #9 of 9 (265 views)
Permalink
Re: Exim 4.80 RC1 uploaded [In reply to]

On 2012-05-20 at 18:24 +0200, Andreas Metzler wrote:
> FWIW I have just uploaded to Debian/experimental to check for
> build-errors. In a first try we are building with -Wformat=security
> and

> -extern BOOL string_format(uschar *, int, const char *, ...) PRINTF_FUNCTION(3,4);
> +extern BOOL string_format(uschar *, int, const char *, ...);
>
> as this has worked for me. ;-)

What is in git now is ALMOST_PRINTF(3,4), which normally expands empty.
Putting WANT_DEEPER_PRINTF_CHECKS=yes into Local/Makefile restores the
attribute. This affects string_format() and string_sprintf().

Doing this, the number of complaints dropped enough that looking at the
few that were left, I was able to fix some real (longstanding) issues.

-Phil

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