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 erro
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
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
Adding backwards-compat items:
* OpenSSL loading of tls_dhparams constrained by new option
tls_dh_max_bits
* Are validating tls_require_ciphers at start-up; note that not only
does this affect invalid strings, but also broken binaries which
previously segfaulted during delivery and mig
On 2012-05-20 at 08:02 -0700, Todd Lyons wrote:
> Do we need to add some detection of openssl version or is this also going
> to be a backwards incompatible change?
There's some around registering the callback but not around defining the
content, an oversight. I'll clean it up a little.
I don't
On 2012-05-20 at 08:26 -0700, Todd Lyons wrote:
> I just pushed a small commit with some additions to the test/README and an
> additional check when the test/runtest script is starting up. I did the
> work on a local topic branch and then merged that with master and pushed.
> I see that nobody els
On 2012-05-21 at 02:45 +0700, Janne Snabb wrote:
> On 2012-05-21 01:34, Janne Snabb wrote:
> > Maybe NSS is unable to create/use bigger keys than 2048 bits?
>
> I found the actual limit in NSS sources in
> mozilla/security/nss/lib/freebl/blapit.h:
You are awesome. Thank you.
> http://sourceforg
On 2012-05-20 at 13:55 +0200, Andreas Metzler wrote:
> tls_require_ciphers seems to be ignored on the server side:
Yup, detected myself while debugging something for GnuTLS stuff and
discovered a missing assign.
> 13:42:57 20416 GnuTLS using default session cipher/priority "NORMAL"
On the bright
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 co
On 2012-05-20 at 08:55 -0700, Todd Lyons wrote:
> On Sat, May 19, 2012 at 3:01 PM, Phil Pennock 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
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 BOOLstring_format(uschar *, int, const char *, ...)
> PRINTF_FUNCTION(3,4);
> +extern BOO
On 2012-05-21 01:34, Janne Snabb wrote:
> Maybe NSS is unable to create/use bigger keys than 2048 bits?
I found the actual limit in NSS sources in
mozilla/security/nss/lib/freebl/blapit.h:
#define DH_MAX_P_BITS 2236
Thus DHE keys up to 2236 bits do work, but longer keys cause the
observe
On 2012-05-20 17:35, Phil Pennock wrote:
> I don't see a better error code for peer EOF, but calling EOF a record
> overflow is still a little confusing to dumbasses like me.
I agree, EOF handling in GnuTLS does not look very convincing.
> Okay, is clearly NSS disliking the server_hello_done.
I
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/lis
On 2012-05-19 Phil Pennock 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() u
On 2012-05-20 16:26, Todd Lyons wrote:
I just pushed a small commit with some additions to the test/README and an
additional check when the test/runtest script is starting up. I did the
work on a local topic branch and then merged that with master and pushed.
I see that nobody else has merge com
On Sat, May 19, 2012 at 3:01 PM, Phil Pennock 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 alrea
I just pushed a small commit with some additions to the test/README and an
additional check when the test/runtest script is starting up. I did the
work on a local topic branch and then merged that with master and pushed.
I see that nobody else has merge commit messages, so is everybody just
commit
The addition of a new TLS capability (SNI) seems to have left CentOS 5.x
out in the cold. C5x comes with (by now a heavily patched) openssl 0.9.8e,
which does not support SNI. Quoting from
http://stackoverflow.com/questions/7340784/easy-install-pyopenssl-error :
"Support for SNI was introduced i
Hello,
tls_require_ciphers seems to be ignored on the server side:
argenau:/tmp/EXIM4# exim4 -bP tls_require_ciphers
tls_require_ciphers = EXPORT:-VERS-TLS1.2
argenau:/tmp/EXIM4# exim4 -bd -d+all-memory -v
Library version: GnuTLS: Compile: 2.12.19
Runtime: 2.12.19
[...]
On 2012-05-20 at 17:11 +0700, Janne Snabb wrote:
> On 2012-05-20 16:24, Phil Pennock wrote:
> > I find it interesting that ssltap does show the length=4 packet but
> > *not* the length=9 packet which GnuTLS claims it was sent.
>
> Look at the log closer:
*sigh* I wish I hadn't run Thunderbird ;)
On 2012-05-20 Phil Pennock wrote:
> On 2012-05-20 at 11:23 +0200, Andreas Metzler wrote:
> > gmane's exim-dev archive has stopped updating. Could some list admin
> > check wether the problem is on tahini's side (disabled delivery) or on
> > gmanes's side?
> Gmane's subscription in mailman is stil
On 2012-05-20 at 11:23 +0200, Andreas Metzler wrote:
> gmane's exim-dev archive has stopped updating. Could some list admin
> check wether the problem is on tahini's side (disabled delivery) or on
> gmanes's side?
Gmane's subscription in mailman is still active, "nomail" is not set.
No mail queue
On 2012-05-20 at 12:14 +0700, Janne Snabb wrote:
> It appears that:
>
> - If I compile Exim 4.80 RC2 with GnuTLS (2.8.5-4.el6_2.2) on Scientific
> Linux 6.2 I do not have problems connecting to it with NSS based client
> (no matter if the client is shipped by SL or Ubuntu).
>
> - If I attempt to
Hello,
gmane's exim-dev archive has stopped updating. Could some list admin
check wether the problem is on tahini's side (disabled delivery) or on
gmanes's side?
thanks, 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
On 2012-05-20 Phil Pennock wrote:
> On 2012-05-19 at 20:17 +0100, Nigel Metheringham wrote:
> > Not sure - OED says writeable is an alternate form of writable [ see
> > http://yfrog.com/oct3hdfj ], which sort of suggests writable is the
> Chambers 21st century lists neither writable nor writeable
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 wh
27 matches
Mail list logo
