From n.mavrogiannopoulos at gmail.com  Mon Mar  3 15:37:36 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 03 Mar 2008 16:37:36 +0200
Subject: Problems with specific certificate/key (Debian Bug #426013)
In-Reply-To: <20080228132642.GA15966@campbell-lange.net>
References: <20080227174940.GA1479@campbell-lange.net>
	<47C5D0F6.2060506@gmail.com>
	<20080228125146.GA12714@campbell-lange.net>
	<20080228132642.GA15966@campbell-lange.net>
Message-ID: <47CC0D30.8000805@gmail.com>

> All, This is now working as desired. I am using exactly the same
> configuration as I detailed in my first post (it was commented, I
> uncommented it.)
> 
> MAIN_TLS_ENABLE = yes
> MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem
> MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt
> 
> Does anyone know if any recent updates could have corrected this
> problem?

The gnutls_certificate_set_x509_key_file() of 2.2.x series of gnutls can 
read PKCS8 private keys (when not encrypted). This might have been the 
issue.

However if you have indicated that your private key header started as 
"BEGIN PRIVATE KEY" you might have helped solve this much earlier :)

regards,
Nikos






From simon at josefsson.org  Wed Mar  5 17:47:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 05 Mar 2008 17:47:57 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
Message-ID: <87y78xi0ci.fsf@mocca.josefsson.org>

All,

I've created a wiki page to explain how to benchmark mod_gnutls vs
mod_ssl with apache2 using only official debian packages.

http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/BenchmarkingModGnuTLS

The initial results place mod_gnutls at 50-75% of the performance of
mod_ssl, which was higher than what I would have guessed.  We haven't
done any organized optimizations.

Results from other architectures or operating systems are very welcome.
Just add the output at the end of the page, under a new 'Results from X'
heading.

One interesting behaviour I noticed when running the tests was that with
mod_ssl, the exchanged TCP packets as seen in wireshark were:

-> client hello
<- server hello, certificate, server key exchange, server hello done
-> client key exchange, change cipher spec, encrypted handshake message
<- change cipher spec, encrypted handshake message
...

but with gnutls we have:

-> client hello
<- server hello
<- certificate
<- server key exchange
<- server hello done
->client key exchange, change cipher spec, encrypted handshake message
<- change cipher spec
<- encrypted handshake message

In other words, gnutls sends each TLS packet in a separate TCP packet.
This may have some impact on performance, but it is too early to tell
for sure.

/Simon




From chip at corelands.com  Thu Mar  6 23:43:59 2008
From: chip at corelands.com (Paul Querna)
Date: Thu, 6 Mar 2008 14:43:59 -0800
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87y78xi0ci.fsf@mocca.josefsson.org>
References: <87y78xi0ci.fsf@mocca.josefsson.org>
Message-ID: <4239a4320803061443t51cff991meec738e004a39a3d@mail.gmail.com>

On 3/5/08, Simon Josefsson <simon at josefsson.org> wrote:
>
> All,
>
> I've created a wiki page to explain how to benchmark mod_gnutls vs
> mod_ssl with apache2 using only official debian packages.
>
> http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/BenchmarkingModGnuTLS
>
> The initial results place mod_gnutls at 50-75% of the performance of
> mod_ssl, which was higher than what I would have guessed.  We haven't
> done any organized optimizations.
>
> Results from other architectures or operating systems are very welcome.
> Just add the output at the end of the page, under a new 'Results from X'
> heading.
>
> One interesting behaviour I noticed when running the tests was that with
> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>
> -> client hello
> <- server hello, certificate, server key exchange, server hello done
> -> client key exchange, change cipher spec, encrypted handshake message
> <- change cipher spec, encrypted handshake message
> ...
>
> but with gnutls we have:
>
> -> client hello
> <- server hello
> <- certificate
> <- server key exchange
> <- server hello done
> ->client key exchange, change cipher spec, encrypted handshake message
> <- change cipher spec
> <- encrypted handshake message
>
> In other words, gnutls sends each TLS packet in a separate TCP packet.
> This may have some impact on performance, but it is too early to tell
> for sure.



This might be a bug in mod_gnutls -- we might want to add some smarter
buffering / picking when we do a flush(). Right now I believe we try to
flush every time gnutls says there is data to send.


It also would be nice if the gnutls API had a better way to say "flush",
rather than just "here is data", although the current API is simple :-)

-Paul



/Simon
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080306/84d66581/attachment.htm>

From Halton.Huo at Sun.COM  Thu Mar  6 17:35:52 2008
From: Halton.Huo at Sun.COM (Halton Huo)
Date: Fri, 07 Mar 2008 00:35:52 +0800
Subject: build fail on Solaris
Message-ID: <1204821352.986.4.camel@judo>

Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 

The simple patch is attached, not sure it __func__ works fine on Linux.


BTW, how can I file bugs against gnutls, Richard Frith said it is not
correct?

Thanks,
Haltons.





From simon at josefsson.org  Fri Mar  7 10:04:28 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Mar 2008 10:04:28 +0100
Subject: gnutls guile self checks fail: fport_fill_input
Message-ID: <87lk4uoqg3.fsf@mocca.josefsson.org>

Hi Ludovic.

The guile self-tests seem to fail:

jas at mocca:~/src/gnutls/guile/tests$ make check
make  check-TESTS
make[1]: Entering directory `/home/jas/src/gnutls/guile/tests'
ERROR: In procedure fport_fill_input:
ERROR: Is a directory
FAIL: anonymous-auth.scm
...

I couldn't find these error message inside gnutls, so they could be
guile bugs, but I suspect you know better than me how to debug this.

Strace shows something that may be related: it seems to open / but fails
because it is a directory.

/Simon

read(5, "le-use! guile-user-module (resol"..., 4096) = 2078
stat64("/usr/share/guile/site/ice-9/deprecated.scm", 0xbfce2034) = -1 ENOENT (No such file or directory)
stat64("/usr/share/guile/1.8/ice-9/deprecated.scm", {st_mode=S_IFREG|0644, st_size=6159, ...}) = 0
open("/usr/share/guile/1.8/ice-9/deprecated.scm", O_RDONLY|O_LARGEFILE) = 6
fcntl64(6, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
lseek(6, 0, SEEK_CUR)                   = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=6159, ...}) = 0
select(1024, [6], [], [], {0, 0})       = 1 (in [6], left {0, 0})
read(6, ";;;; Copyright (C) 2003, 2005, 2"..., 4096) = 4096
select(1024, [6], [], [], {0, 0})       = 1 (in [6], left {0, 0})
read(6, "\t\t\t\t  module-name)))))\n    (let "..., 4096) = 2063
select(1024, [6], [], [], {0, 0})       = 1 (in [6], left {0, 0})
read(6, "", 4096)                       = 0
close(6)                                = 0
select(1024, [5], [], [], {0, 0})       = 1 (in [5], left {0, 0})
read(5, "", 4096)                       = 0
close(5)                                = 0
open("/", O_RDONLY|O_LARGEFILE)         = 5
fcntl64(5, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
lseek(5, 0, SEEK_CUR)                   = 0
fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
select(1024, [5], [], [], {0, 0})       = 1 (in [5], left {0, 0})
read(5, 0x80688a0, 4096)                = -1 EISDIR (Is a directory)
write(2, "ERROR", 5ERROR)                    = 5
write(2, ": ", 2: )                       = 2
write(2, "In procedure ", 13In procedure )           = 13
write(2, "fport_fill_input", 16fport_fill_input)        = 16
write(2, ":\n", 2:
)                      = 2
write(2, "ERROR", 5ERROR)                    = 5
write(2, ": ", 2: )                       = 2
write(2, "Is a directory", 14Is a directory)          = 14
write(2, "\n", 1




From simon at josefsson.org  Fri Mar  7 10:08:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Mar 2008 10:08:42 +0100
Subject: build fail on Solaris
In-Reply-To: <1204821352.986.4.camel@judo> (Halton Huo's message of "Fri, 07
	Mar 2008 00:35:52 +0800")
References: <1204821352.986.4.camel@judo>
Message-ID: <87fxv2lx45.fsf@mocca.josefsson.org>

Halton Huo <Halton.Huo at Sun.COM> writes:

> Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 
>
> The simple patch is attached, not sure it __func__ works fine on Linux.

Yes, we should use __func__.  This has already been fixed on the trunk,
but not for 2.2.x.  I'll backport it.

> BTW, how can I file bugs against gnutls, Richard Frith said it is not
> correct?

The bug tracker you used was for GNUstep.  You can find information
about GnuTLS bug reporting at:

http://www.gnu.org/software/gnutls/bugs.html

As it happens, this problem was already reported there, see:

https://savannah.gnu.org/support/?106267

/Simon




From ludo at gnu.org  Fri Mar  7 11:47:23 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 07 Mar 2008 11:47:23 +0100
Subject: gnutls guile self checks fail: fport_fill_input
References: <87lk4uoqg3.fsf@mocca.josefsson.org>
Message-ID: <8763vyak04.fsf@gnu.org>

Hi Simon,

First of all, sorry for not being more involved...

Simon Josefsson <simon at josefsson.org> writes:

> jas at mocca:~/src/gnutls/guile/tests$ make check
> make  check-TESTS
> make[1]: Entering directory `/home/jas/src/gnutls/guile/tests'
> ERROR: In procedure fport_fill_input:
> ERROR: Is a directory
> FAIL: anonymous-auth.scm
> ...

I can't reproduce the problem here with a copy of `master'.  Does
`openpgp-auth.scm' (or other tests) fail similarly?  What platform is
this on?

> I couldn't find these error message inside gnutls, so they could be
> guile bugs, but I suspect you know better than me how to debug this.
>
> Strace shows something that may be related: it seems to open / but fails
> because it is a directory.

That seems to be the problem here: a Guile input port has been created
for `/' and is being read from, which fails.  I can't find why this
happens.

Can you show the value of `$GUILE_LOAD_PATH' and all the `-L' switches
passed to `guile' (see `guile/pre-inst-guile' and `TESTS_ENVIRONMENT' in
`guile/tests/Makefile.am')?

Can you also send me the whole `strace' output, if possible?

Thanks,
Ludovic.





From Halton.Huo at Sun.COM  Fri Mar  7 10:31:22 2008
From: Halton.Huo at Sun.COM (Halton Huo)
Date: Fri, 07 Mar 2008 17:31:22 +0800
Subject: build fail on Solaris
In-Reply-To: <87fxv2lx45.fsf@mocca.josefsson.org>
References: <1204821352.986.4.camel@judo> <87fxv2lx45.fsf@mocca.josefsson.org>
Message-ID: <1204882282.986.13.camel@judo>

Cool, thanks for the information.

How can I access trunk? I can not find any doc to tell me that.

Thanks,
Halton.
On Fri, 2008-03-07 at 10:08 +0100, Simon Josefsson wrote:
> Halton Huo <Halton.Huo at Sun.COM> writes:
> 
> > Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 
> >
> > The simple patch is attached, not sure it __func__ works fine on Linux.
> 
> Yes, we should use __func__.  This has already been fixed on the trunk,
> but not for 2.2.x.  I'll backport it.
> 
> > BTW, how can I file bugs against gnutls, Richard Frith said it is not
> > correct?
> 
> The bug tracker you used was for GNUstep.  You can find information
> about GnuTLS bug reporting at:
> 
> http://www.gnu.org/software/gnutls/bugs.html
> 
> As it happens, this problem was already reported there, see:
> 
> https://savannah.gnu.org/support/?106267
> 
> /Simon





From armin at graefe-forchheim.de  Fri Mar  7 15:07:32 2008
From: armin at graefe-forchheim.de (=?iso-8859-1?q?=61=72=6d=69=6e=20=67=72=e4=66=65?=)
Date: Fri, 7 Mar 2008 15:07:32 +0100 (MET)
Subject: Problems with certtool, version 1.2.10. Libgnutls 1.2.10
Message-ID: <200803071407.m27E7W4J009700@post.webmailer.de>

An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080307/a8541b1e/attachment.htm>
-------------- next part --------------
Hi there,

Sorry for bothering you, I didn't find meaningful information about the little issue I have using certtool.
 I run a SLES10 (x86) and the command line that I entered was
certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem

(as seen on http://www.linux-ha.org/QuorumServerGuide )
Now the tool keeps telling me

The certificate will expire in (days): 1000
Trailing garbage ignored: `
'
no matter what I enter (using either a GNOME terminal or a remote puTTY session).
Can you give me a hint?

Thanks in advance,
Armin

armin at graefe-forchheim.de
or service at agdv.de
phone: +49 160 9595 1562

From simon at josefsson.org  Fri Mar  7 16:06:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Mar 2008 16:06:46 +0100
Subject: build fail on Solaris
In-Reply-To: <1204882282.986.13.camel@judo> (Halton Huo's message of "Fri, 07
	Mar 2008 17:31:22 +0800")
References: <1204821352.986.4.camel@judo> <87fxv2lx45.fsf@mocca.josefsson.org>
	<1204882282.986.13.camel@judo>
Message-ID: <877igelgjd.fsf@mocca.josefsson.org>

Click on 'Developers site' from the gnutls home page leads to:

http://trac.gnutls.org/

There you'll find information how to check out trunk.

/Simon

Halton Huo <Halton.Huo at Sun.COM> writes:

> Cool, thanks for the information.
>
> How can I access trunk? I can not find any doc to tell me that.
>
> Thanks,
> Halton.
> On Fri, 2008-03-07 at 10:08 +0100, Simon Josefsson wrote:
>> Halton Huo <Halton.Huo at Sun.COM> writes:
>> 
>> > Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 
>> >
>> > The simple patch is attached, not sure it __func__ works fine on Linux.
>> 
>> Yes, we should use __func__.  This has already been fixed on the trunk,
>> but not for 2.2.x.  I'll backport it.
>> 
>> > BTW, how can I file bugs against gnutls, Richard Frith said it is not
>> > correct?
>> 
>> The bug tracker you used was for GNUstep.  You can find information
>> about GnuTLS bug reporting at:
>> 
>> http://www.gnu.org/software/gnutls/bugs.html
>> 
>> As it happens, this problem was already reported there, see:
>> 
>> https://savannah.gnu.org/support/?106267
>> 
>> /Simon




From Halton.Huo at Sun.COM  Fri Mar  7 16:13:08 2008
From: Halton.Huo at Sun.COM (Halton Huo)
Date: Fri, 07 Mar 2008 23:13:08 +0800
Subject: build fail on Solaris
In-Reply-To: <877igelgjd.fsf@mocca.josefsson.org>
References: <1204821352.986.4.camel@judo> <87fxv2lx45.fsf@mocca.josefsson.org>
	<1204882282.986.13.camel@judo> <877igelgjd.fsf@mocca.josefsson.org>
Message-ID: <1204902788.2410.1.camel@localhost>

Cool~~

Notice there are bug system on this site, why not use this one as GNUTls
bug system?

Halton.
On Fri, 2008-03-07 at 16:06 +0100, Simon Josefsson wrote:
> Click on 'Developers site' from the gnutls home page leads to:
> 
> http://trac.gnutls.org/
> 
> There you'll find information how to check out trunk.
> 
> /Simon
> 
> Halton Huo <Halton.Huo at Sun.COM> writes:
> 
> > Cool, thanks for the information.
> >
> > How can I access trunk? I can not find any doc to tell me that.
> >
> > Thanks,
> > Halton.
> > On Fri, 2008-03-07 at 10:08 +0100, Simon Josefsson wrote:
> >> Halton Huo <Halton.Huo at Sun.COM> writes:
> >> 
> >> > Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 
> >> >
> >> > The simple patch is attached, not sure it __func__ works fine on Linux.
> >> 
> >> Yes, we should use __func__.  This has already been fixed on the trunk,
> >> but not for 2.2.x.  I'll backport it.
> >> 
> >> > BTW, how can I file bugs against gnutls, Richard Frith said it is not
> >> > correct?
> >> 
> >> The bug tracker you used was for GNUstep.  You can find information
> >> about GnuTLS bug reporting at:
> >> 
> >> http://www.gnu.org/software/gnutls/bugs.html
> >> 
> >> As it happens, this problem was already reported there, see:
> >> 
> >> https://savannah.gnu.org/support/?106267
> >> 
> >> /Simon





From simon at josefsson.org  Fri Mar  7 16:27:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Mar 2008 16:27:05 +0100
Subject: build fail on Solaris
In-Reply-To: <1204902788.2410.1.camel@localhost> (Halton Huo's message of
	"Fri, 07 Mar 2008 23:13:08 +0800")
References: <1204821352.986.4.camel@judo> <87fxv2lx45.fsf@mocca.josefsson.org>
	<1204882282.986.13.camel@judo> <877igelgjd.fsf@mocca.josefsson.org>
	<1204902788.2410.1.camel@localhost>
Message-ID: <873ar2imgm.fsf@mocca.josefsson.org>

Halton Huo <Halton.Huo at Sun.COM> writes:

> Cool~~
>
> Notice there are bug system on this site, why not use this one as GNUTls
> bug system?

We are using it.  We also use the savannah bug tracking system (but you
must file the bug under 'gnutls' instead of under another project).

I guess we simply haven't decided which one to prefer.  Trac gives us
other features that we need (e.g., wiki) and it came with a issue
tracker.  Possibly we could switch to using only trac, or we could
switch to only use the savannah tracker.  If we use issue tracking in
Trac we get nice integration between tickets and the wiki, milestones,
timeline, etc though.  Thoughts?

/Simon

> Halton.
> On Fri, 2008-03-07 at 16:06 +0100, Simon Josefsson wrote:
>> Click on 'Developers site' from the gnutls home page leads to:
>> 
>> http://trac.gnutls.org/
>> 
>> There you'll find information how to check out trunk.
>> 
>> /Simon
>> 
>> Halton Huo <Halton.Huo at Sun.COM> writes:
>> 
>> > Cool, thanks for the information.
>> >
>> > How can I access trunk? I can not find any doc to tell me that.
>> >
>> > Thanks,
>> > Halton.
>> > On Fri, 2008-03-07 at 10:08 +0100, Simon Josefsson wrote:
>> >> Halton Huo <Halton.Huo at Sun.COM> writes:
>> >> 
>> >> > Please look at the bug I filed on https://savannah.gnu.org/bugs/?22504 
>> >> >
>> >> > The simple patch is attached, not sure it __func__ works fine on Linux.
>> >> 
>> >> Yes, we should use __func__.  This has already been fixed on the trunk,
>> >> but not for 2.2.x.  I'll backport it.
>> >> 
>> >> > BTW, how can I file bugs against gnutls, Richard Frith said it is not
>> >> > correct?
>> >> 
>> >> The bug tracker you used was for GNUstep.  You can find information
>> >> about GnuTLS bug reporting at:
>> >> 
>> >> http://www.gnu.org/software/gnutls/bugs.html
>> >> 
>> >> As it happens, this problem was already reported there, see:
>> >> 
>> >> https://savannah.gnu.org/support/?106267
>> >> 
>> >> /Simon




From Halton.Huo at Sun.COM  Fri Mar  7 16:36:52 2008
From: Halton.Huo at Sun.COM (Halton Huo)
Date: Fri, 07 Mar 2008 23:36:52 +0800
Subject: build fail on Solaris
In-Reply-To: <873ar2imgm.fsf@mocca.josefsson.org>
References: <1204821352.986.4.camel@judo> <87fxv2lx45.fsf@mocca.josefsson.org>
	<1204882282.986.13.camel@judo> <877igelgjd.fsf@mocca.josefsson.org>
	<1204902788.2410.1.camel@localhost>
	<873ar2imgm.fsf@mocca.josefsson.org>
Message-ID: <1204904212.2410.8.camel@localhost>


>From my experience, I'd like to choose Trac.

I've used kinds of bug systems: bugzilla(most popular), Trac,
sourceforge Track. Never use system like savannah tracker.


Halton.
 
On Fri, 2008-03-07 at 16:27 +0100, Simon Josefsson wrote:
> We are using it.  We also use the savannah bug tracking system (but
> you
> must file the bug under 'gnutls' instead of under another project).
> 
> I guess we simply haven't decided which one to prefer.  Trac gives us
> other features that we need (e.g., wiki) and it came with a issue
> tracker.  Possibly we could switch to using only trac, or we could
> switch to only use the savannah tracker.  If we use issue tracking in
> Trac we get nice integration between tickets and the wiki, milestones,
> timeline, etc though.  Thoughts?
> 
> /Simon





From vulncoord at ficora.fi  Fri Mar  7 08:42:15 2008
From: vulncoord at ficora.fi (CERT-FI Vulnerability Coordination)
Date: Fri, 7 Mar 2008 09:42:15 +0200
Subject: [FICORA #130447] Vulnerability issue co-ordination
Message-ID: <07BC6C0D40216E44A34BE6701694FE860546C4F5@POSTI.laru.local>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Good Morning,

I am in charge of vulnerability co-ordination in CERT-FI, the Finnish
national Computer Emergency Response Team. We are currently handling,
a vulnerability case which potentially involves your products.

I would like to PGP, S/MIME or other cryptographic keys with you to
share vulnerability data and discuss the case in a secure manner. You
can find our PGP key for vulnerability co-ordination, and my personal
S/MIME keys in my signature.

The case at hand is classified AMBER in the Traffic Light Protocol 
as described in the following URL:

http://scni.jrc.it/03-projects/06-E-SCSIE/index#ANNEX_TLP

Best Regards,

- -Jussi

- -- 
Juhani Eronen / CERT-FI vulnerability co-ordination
E-mail: vulncoord at ficora.fi, Web: http://www.cert.fi
PGP: https://www.cert.fi/en/activities/contact/pgp-keys.html
Fingerprint: 3746 C101 5A67 4A30 DF81 9C38 FFAE 1A0B 613E C8AF
Personal keys: 
http://www.cert.fi/palvelut/yhteystiedot/henkilokohtaiset_avaimet.html

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBR9DssP+uGgthPsivEQIQDQCeIQ3i9MJ+0icDILCvf9RvON8Nm7EAoKdp
OgmDZ0Qx7LV343pBQzAnoEDT
=AvxR
-----END PGP SIGNATURE-----




From ametzler at downhill.at.eu.org  Sat Mar  8 09:48:18 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 8 Mar 2008 09:48:18 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87fxwe4d0g.fsf@wheatstone.g10code.de>
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
Message-ID: <20080308084818.GC3091@downhill.g.la>

On 2008-01-31 Werner Koch <wk at gnupg.org> wrote:
> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said:

>> Any obvious breakage? Exim does not use any threading. I have not
>> included an gcry_check_version(NULL) since I thought gcry_control()
>> would fail as reliably as gcry_check_version() would, if gcrypt was

> Better insert a gcry_check_version because this is the safe way to
> initialize gcrypt.  The initialization is also done with most other
> gcry_control calls but that is a failsafe feature.  Explicitly
> initialization is better (you don't need to check the return code, just
> call it.)

Hello,

we still seem have not been able to find a really working solution,
this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
causes crashes in exim.

Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
| However, the secondary MX (which delivers some spam to the primary MX) noted
| that the primary box had become unreliable in TLS:
| 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
| [85.214.68.41] closed connection in response to STARTTLS
| 
| When this happened (a couple of times per hour), I didn't get any
| atypical log entries on mailgate.
| 
| This was a repeating, but intermittent failure since mailgate
| continued to work normally, and STARTTLS was successful most of the
| time.
[...]
| Going back to the same exim sans the random-seed patch, entropy
| average went back to 200, but the STARTTLS failures vanished.

We have tried to isolate what actually breaks, by only applying parts
of the patch (e.g setting up dthe seed file, but not updating it.),
but it looks like the mere presence of
gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
causes the crashes.

I am really wondering whether using the experimental daemon might be
worthwile, there does not seem to be much cost involved, and
/dev/(u)random has not got any policy controls either.
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'




From simon at josefsson.org  Sat Mar  8 10:40:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 08 Mar 2008 10:40:08 +0100
Subject: [FICORA #130447] Vulnerability issue co-ordination
In-Reply-To: <07BC6C0D40216E44A34BE6701694FE860546C4F5@POSTI.laru.local>
	(CERT-FI Vulnerability Coordination's message of "Fri, 7 Mar 2008
	09:42:15 +0200")
References: <07BC6C0D40216E44A34BE6701694FE860546C4F5@POSTI.laru.local>
Message-ID: <87od9pbll3.fsf@mocca.josefsson.org>

"CERT-FI Vulnerability Coordination" <vulncoord at ficora.fi> writes:

> Good Morning,
>
> I am in charge of vulnerability co-ordination in CERT-FI, the Finnish
> national Computer Emergency Response Team. We are currently handling,
> a vulnerability case which potentially involves your products.
>
> I would like to PGP, S/MIME or other cryptographic keys with you to
> share vulnerability data and discuss the case in a secure manner. You
> can find our PGP key for vulnerability co-ordination, and my personal
> S/MIME keys in my signature.

You can find my PGP key in the GnuTLS distribution itself (in the
AUTHORS file), or retrieve it from <http://josefsson.org/key.txt>, or
retrieve the key from any PGP key server searching for the fingerprint
that signs GnuTLS distributions (i.e., b565716f).

Thanks,
/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080308/cf7f6532/attachment.pgp>

From simon at josefsson.org  Sat Mar  8 10:44:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 08 Mar 2008 10:44:13 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <87k5kdblea.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2008-01-31 Werner Koch <wk at gnupg.org> wrote:
>> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said:
>
>>> Any obvious breakage? Exim does not use any threading. I have not
>>> included an gcry_check_version(NULL) since I thought gcry_control()
>>> would fail as reliably as gcry_check_version() would, if gcrypt was
>
>> Better insert a gcry_check_version because this is the safe way to
>> initialize gcrypt.  The initialization is also done with most other
>> gcry_control calls but that is a failsafe feature.  Explicitly
>> initialization is better (you don't need to check the return code, just
>> call it.)
>
> Hello,
>
> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.
>
> Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654
> | However, the secondary MX (which delivers some spam to the primary MX) noted
> | that the primary box had become unreliable in TLS:
> | 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de
> | [85.214.68.41] closed connection in response to STARTTLS
> | 
> | When this happened (a couple of times per hour), I didn't get any
> | atypical log entries on mailgate.
> | 
> | This was a repeating, but intermittent failure since mailgate
> | continued to work normally, and STARTTLS was successful most of the
> | time.
> [...]
> | Going back to the same exim sans the random-seed patch, entropy
> | average went back to 200, but the STARTTLS failures vanished.
>
> We have tried to isolate what actually breaks, by only applying parts
> of the patch (e.g setting up dthe seed file, but not updating it.),
> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

Did you follow Werner's suggestion to the patch?  I.e., to call
gcry_check_version to initialize libgcrypt properly.

> I am really wondering whether using the experimental daemon might be
> worthwile, there does not seem to be much cost involved, and
> /dev/(u)random has not got any policy controls either.

I think doing whatever it takes to make libgcrypt return useful amounts
of entropy would be a good thing.  Forcing every application to set a
seed file is quite costly maintenance and documentation wise, so running
one libgcrypt-specific daemon may be simpler.

/Simon




From ametzler at downhill.at.eu.org  Sat Mar  8 11:11:51 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 8 Mar 2008 11:11:51 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87k5kdblea.fsf@mocca.josefsson.org>
References: <87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87k5kdblea.fsf@mocca.josefsson.org>
Message-ID: <20080308101151.GD3091@downhill.g.la>

On 2008-03-08 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > We have tried to isolate what actually breaks, by only applying parts
> > of the patch (e.g setting up dthe seed file, but not updating it.),
> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

> Did you follow Werner's suggestion to the patch?  I.e., to call
> gcry_check_version to initialize libgcrypt properly.

Yes, we did.
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'




From nmav at gnutls.org  Sat Mar  8 12:41:53 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Mar 2008 13:41:53 +0200
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87y78xi0ci.fsf@mocca.josefsson.org>
References: <87y78xi0ci.fsf@mocca.josefsson.org>
Message-ID: <47D27B81.6060409@gnutls.org>

Simon Josefsson wrote:
> All,
> 
> Results from other architectures or operating systems are very welcome.
> Just add the output at the end of the page, under a new 'Results from X'
> heading.
Hello,
  I've added results from an AMD64x2 cpu. The performance of gnutls is 
dramatically better. For a small file (5k) and DHE-RSA ciphersuites the 
performance is equivalent. For the plain RSA ciphersuite the performance 
is still low (about 40% of the openssl performance).

For a larger (300k) file the performance for both ciphersuites is 
exactly the same.

So it seems libgcrypt is quite optimized in amd64... However there seems 
to be some overhead in the plain RSA ciphersuites that affects 
performance when the number of transactions increases (the first case 
with the small file). Possibly the RSA blinding...


> One interesting behaviour I noticed when running the tests was that with
> mod_ssl, the exchanged TCP packets as seen in wireshark were:
[...]
> In other words, gnutls sends each TLS packet in a separate TCP packet.
> This may have some impact on performance, but it is too early to tell
> for sure.

This could also affect the first case where a small file is sent and 
many transactions occur per second.

regards,
Nikos




From novel at FreeBSD.org  Mon Mar 10 10:29:34 2008
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Mon, 10 Mar 2008 12:29:34 +0300
Subject: gnutls 2.3.2 build fail because of opencdk
Message-ID: <20080310092934.GA62715@underworld.novel.ru>

When I try to build gnutls 2.3.2 without opencdk, it fails to build, the
log attached. It seems it fails because there's no
"-I$(top_srcdir)/lib/opencdk" flag in libextra/Makefile.am in
AM_CPPFLAGS variable. However, this problem won't show up on a system
with opencdk installed since it will pick opencdk.h from
/usr/local/include (or whatever standard include path on a system).

Adding -I$(top_srcdir)/lib/opencdk to AM_CPPFLAGS in
libextra/Makefile.am solves the problem for me.

Roman Bogorodskiy
-------------- next part --------------
gmake[3]: Entering directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.2/libextra'
/bin/sh /usr/home/novel/ports_stuff/gnutls-devel/work/gnome-libtool --tag=CC   --mode=compile cc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I/usr/local/include  -I/usr/local/include -I/usr/local/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=k8 -Wno-pointer-sign -MT gnutls_extra.lo -MD -MP -MF .deps/gnutls_extra.Tpo -c -o gnutls_extra.lo gnutls_extra.c
 cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I/usr/local/include -I/usr/local/include -I/usr/local/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=k8 -Wno-pointer-sign -MT gnutls_extra.lo -MD -MP -MF .deps/gnutls_extra.Tpo -c gnutls_extra.c  -fPIC -DPIC -o .libs/gnutls_extra.o
In file included from ../lib/auth_cert.h:31,
                 from ./gnutls_extra.h:25,
                 from gnutls_extra.c:25:
../lib/openpgp/openpgp_int.h:10:21: error: opencdk.h: No such file or directory
In file included from ../lib/auth_cert.h:31,
                 from ./gnutls_extra.h:25,
                 from gnutls_extra.c:25:
../lib/openpgp/openpgp_int.h:20: error: expected specifier-qualifier-list before 'cdk_kbnode_t'
../lib/openpgp/openpgp_int.h:28: error: expected specifier-qualifier-list before 'cdk_kbnode_t'
../lib/openpgp/openpgp_int.h:36: error: expected specifier-qualifier-list before 'cdk_keydb_hd_t'
../lib/openpgp/openpgp_int.h:41: error: expected ')' before 'node'
../lib/openpgp/openpgp_int.h:50: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_gnutls_get_valid_subkey'
../lib/openpgp/openpgp_int.h:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_gnutls_openpgp_find_key'
../lib/openpgp/openpgp_int.h:64: error: expected ')' before 'pkt'
../lib/openpgp/openpgp_int.h:66: error: expected ')' before 'knode'
gmake[3]: *** [gnutls_extra.lo] Error 1
gmake[3]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.2/libextra'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.2/libextra'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.2'
gmake: *** [all] Error 2
*** Error code 2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: </pipermail/attachments/20080310/ab768051/attachment.pgp>

From simon at josefsson.org  Mon Mar 10 10:41:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 10:41:07 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <4239a4320803061443t51cff991meec738e004a39a3d@mail.gmail.com>
	(Paul Querna's message of "Thu, 6 Mar 2008 14:43:59 -0800")
References: <87y78xi0ci.fsf@mocca.josefsson.org>
	<4239a4320803061443t51cff991meec738e004a39a3d@mail.gmail.com>
Message-ID: <87hcfe9arw.fsf@mocca.josefsson.org>

"Paul Querna" <chip at corelands.com> writes:

>> One interesting behaviour I noticed when running the tests was that with
>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>>
>> -> client hello
>> <- server hello, certificate, server key exchange, server hello done
>> -> client key exchange, change cipher spec, encrypted handshake message
>> <- change cipher spec, encrypted handshake message
>> ...
>>
>> but with gnutls we have:
>>
>> -> client hello
>> <- server hello
>> <- certificate
>> <- server key exchange
>> <- server hello done
>> ->client key exchange, change cipher spec, encrypted handshake message
>> <- change cipher spec
>> <- encrypted handshake message
>>
>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>> This may have some impact on performance, but it is too early to tell
>> for sure.
>
> This might be a bug in mod_gnutls -- we might want to add some smarter
> buffering / picking when we do a flush(). Right now I believe we try to
> flush every time gnutls says there is data to send.

Hm, yes, perhaps mod_gnutls could do some buffering.  Or gnutls could do
it internally.

> It also would be nice if the gnutls API had a better way to say "flush",
> rather than just "here is data", although the current API is simple :-)

Aren't there options in the kernel TCP interface to delay sending
packets for some time, to wait for more data that could also be sent in
the same packet?  I have some vague memory about this.

/Simon




From ludo at gnu.org  Mon Mar 10 10:51:09 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 10 Mar 2008 10:51:09 +0100
Subject: gnutls 2.3.2 build fail because of opencdk
References: <20080310092934.GA62715@underworld.novel.ru>
Message-ID: <87k5kagb5e.fsf@gnu.org>

Hi,

Roman Bogorodskiy <novel at FreeBSD.org> writes:

> When I try to build gnutls 2.3.2 without opencdk, it fails to build, the
> log attached. It seems it fails because there's no
> "-I$(top_srcdir)/lib/opencdk" flag in libextra/Makefile.am in
> AM_CPPFLAGS variable. However, this problem won't show up on a system
> with opencdk installed since it will pick opencdk.h from
> /usr/local/include (or whatever standard include path on a system).

Indeed, I noticed it too.

Thanks,
Ludovic.





From mrsam at courier-mta.com  Mon Mar 10 12:00:06 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 10 Mar 2008 07:00:06 -0400
Subject: benchmarking mod_gnutls vs mod_ssl
References: <87y78xi0ci.fsf@mocca.josefsson.org>
	<4239a4320803061443t51cff991meec738e004a39a3d@mail.gmail.com>
	<87hcfe9arw.fsf@mocca.josefsson.org>
Message-ID: <cone.1205146806.355841.6069.500@commodore.email-scan.com>

Simon Josefsson writes:

> "Paul Querna" <chip at corelands.com> writes:
> 
>>> One interesting behaviour I noticed when running the tests was that with
>>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>>>
>>> -> client hello
>>> <- server hello, certificate, server key exchange, server hello done
>>> -> client key exchange, change cipher spec, encrypted handshake message
>>> <- change cipher spec, encrypted handshake message
>>> ...
>>>
>>> but with gnutls we have:
>>>
>>> -> client hello
>>> <- server hello
>>> <- certificate
>>> <- server key exchange
>>> <- server hello done
>>> ->client key exchange, change cipher spec, encrypted handshake message
>>> <- change cipher spec
>>> <- encrypted handshake message
>>>
>>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>>> This may have some impact on performance, but it is too early to tell
>>> for sure.
>>
>> This might be a bug in mod_gnutls -- we might want to add some smarter
>> buffering / picking when we do a flush(). Right now I believe we try to
>> flush every time gnutls says there is data to send.
> 
> Hm, yes, perhaps mod_gnutls could do some buffering.  Or gnutls could do
> it internally.
> 
>> It also would be nice if the gnutls API had a better way to say "flush",
>> rather than just "here is data", although the current API is simple :-)
> 
> Aren't there options in the kernel TCP interface to delay sending
> packets for some time, to wait for more data that could also be sent in
> the same packet?  I have some vague memory about this.

Yes, TCP_CORK via setsockopt. It's Linux specific.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20080310/840105b3/attachment.pgp>

From simon at josefsson.org  Mon Mar 10 12:15:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 12:15:14 +0100
Subject: gnutls 2.3.2 build fail because of opencdk
In-Reply-To: <20080310092934.GA62715@underworld.novel.ru> (Roman Bogorodskiy's
	message of "Mon, 10 Mar 2008 12:29:34 +0300")
References: <20080310092934.GA62715@underworld.novel.ru>
Message-ID: <871w6iomnx.fsf@mocca.josefsson.org>

Roman Bogorodskiy <novel at FreeBSD.org> writes:

> When I try to build gnutls 2.3.2 without opencdk, it fails to build, the
> log attached. It seems it fails because there's no
> "-I$(top_srcdir)/lib/opencdk" flag in libextra/Makefile.am in
> AM_CPPFLAGS variable. However, this problem won't show up on a system
> with opencdk installed since it will pick opencdk.h from
> /usr/local/include (or whatever standard include path on a system).
>
> Adding -I$(top_srcdir)/lib/opencdk to AM_CPPFLAGS in
> libextra/Makefile.am solves the problem for me.

Thanks for the report.  That is a workaround, but the real fix was to
remove libextra/gnutls_extra.h, as far as I could tell it is not needed
any more.  Fixed in trunk, see:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=749abd0331001e05f82967a597552aa6f5db0563

Thanks,
Simon




From simon at josefsson.org  Mon Mar 10 12:45:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 12:45:01 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <cone.1205146806.355841.6069.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Mon, 10 Mar 2008 07:00:06 -0400")
References: <87y78xi0ci.fsf@mocca.josefsson.org>
	<4239a4320803061443t51cff991meec738e004a39a3d@mail.gmail.com>
	<87hcfe9arw.fsf@mocca.josefsson.org>
	<cone.1205146806.355841.6069.500@commodore.email-scan.com>
Message-ID: <87tzjen6pu.fsf@mocca.josefsson.org>

Sam Varshavchik <mrsam at courier-mta.com> writes:

> Simon Josefsson writes:
>
>> "Paul Querna" <chip at corelands.com> writes:
>>
>>>> One interesting behaviour I noticed when running the tests was that with
>>>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>>>>
>>>> -> client hello
>>>> <- server hello, certificate, server key exchange, server hello done
>>>> -> client key exchange, change cipher spec, encrypted handshake message
>>>> <- change cipher spec, encrypted handshake message
>>>> ...
>>>>
>>>> but with gnutls we have:
>>>>
>>>> -> client hello
>>>> <- server hello
>>>> <- certificate
>>>> <- server key exchange
>>>> <- server hello done
>>>> ->client key exchange, change cipher spec, encrypted handshake message
>>>> <- change cipher spec
>>>> <- encrypted handshake message
>>>>
>>>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>>>> This may have some impact on performance, but it is too early to tell
>>>> for sure.
>>>
>>> This might be a bug in mod_gnutls -- we might want to add some smarter
>>> buffering / picking when we do a flush(). Right now I believe we try to
>>> flush every time gnutls says there is data to send.
>>
>> Hm, yes, perhaps mod_gnutls could do some buffering.  Or gnutls could do
>> it internally.
>>
>>> It also would be nice if the gnutls API had a better way to say "flush",
>>> rather than just "here is data", although the current API is simple :-)
>>
>> Aren't there options in the kernel TCP interface to delay sending
>> packets for some time, to wait for more data that could also be sent in
>> the same packet?  I have some vague memory about this.
>
> Yes, TCP_CORK via setsockopt. It's Linux specific.

Thanks for the pointer.  I've read some documentation about it at:

http://linux.die.net/man/7/tcp
http://articles.techrepublic.com.com/5100-22-1050878.html

However, I'm not convinced it is a good idea for mod_gnutls to always
use it.  The first article suggests it may introduce a 200ms delay when
collecting data, which could hurt benchmarking.  Maybe we could try just
as an experiment to see if we get different results.

/Simon




From simon at josefsson.org  Mon Mar 10 12:48:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 12:48:50 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <47D27B81.6060409@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 08 Mar 2008 13:41:53 +0200")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
Message-ID: <87myp6n6jh.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>> All,
>>
>> Results from other architectures or operating systems are very welcome.
>> Just add the output at the end of the page, under a new 'Results from X'
>> heading.
> Hello,
>  I've added results from an AMD64x2 cpu.

Thanks.

> The performance of gnutls is dramatically better. For a small file
> (5k) and DHE-RSA ciphersuites the performance is equivalent. For the
> plain RSA ciphersuite the performance is still low (about 40% of the
> openssl performance).
>
> For a larger (300k) file the performance for both ciphersuites is
> exactly the same.
>
> So it seems libgcrypt is quite optimized in amd64... However there
> seems to be some overhead in the plain RSA ciphersuites that affects
> performance when the number of transactions increases (the first case
> with the small file). Possibly the RSA blinding...

Yeah, or the TCP stack becomes the bottleneck since gnutls sends more
packets than mod_ssl.  Although this needs more investigation, my guess
is that the TCP overhead for another packet is pretty small.  Especially
when run on localhost.

>> One interesting behaviour I noticed when running the tests was that with
>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
> [...]
>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>> This may have some impact on performance, but it is too early to tell
>> for sure.
>
> This could also affect the first case where a small file is sent and
> many transactions occur per second.

Exactly.

/Simon




From nmav at gnutls.org  Mon Mar 10 12:53:05 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Mar 2008 13:53:05 +0200
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87myp6n6jh.fsf@mocca.josefsson.org>
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp6n6jh.fsf@mocca.josefsson.org>
Message-ID: <47D52121.90206@gnutls.org>

Simon Josefsson wrote:

>> The performance of gnutls is dramatically better. For a small file
>> (5k) and DHE-RSA ciphersuites the performance is equivalent. For the
>> plain RSA ciphersuite the performance is still low (about 40% of the
>> openssl performance).
>>
>> For a larger (300k) file the performance for both ciphersuites is
>> exactly the same.
>>
>> So it seems libgcrypt is quite optimized in amd64... However there
>> seems to be some overhead in the plain RSA ciphersuites that affects
>> performance when the number of transactions increases (the first case
>> with the small file). Possibly the RSA blinding...
> 
> Yeah, or the TCP stack becomes the bottleneck since gnutls sends more
> packets than mod_ssl.  Although this needs more investigation, my guess
> is that the TCP overhead for another packet is pretty small.  Especially
> when run on localhost.

The tests for amd64 were done using a 100mbit ethernet switch and two 
different pc's for client and server.


regards,
Nikos




From simon at josefsson.org  Mon Mar 10 12:58:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 12:58:31 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <47D52121.90206@gnutls.org> (Nikos Mavrogiannopoulos's message of
	"Mon, 10 Mar 2008 13:53:05 +0200")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp6n6jh.fsf@mocca.josefsson.org> <47D52121.90206@gnutls.org>
Message-ID: <87d4q2n63c.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>>> The performance of gnutls is dramatically better. For a small file
>>> (5k) and DHE-RSA ciphersuites the performance is equivalent. For the
>>> plain RSA ciphersuite the performance is still low (about 40% of the
>>> openssl performance).
>>>
>>> For a larger (300k) file the performance for both ciphersuites is
>>> exactly the same.
>>>
>>> So it seems libgcrypt is quite optimized in amd64... However there
>>> seems to be some overhead in the plain RSA ciphersuites that affects
>>> performance when the number of transactions increases (the first case
>>> with the small file). Possibly the RSA blinding...
>>
>> Yeah, or the TCP stack becomes the bottleneck since gnutls sends more
>> packets than mod_ssl.  Although this needs more investigation, my guess
>> is that the TCP overhead for another packet is pretty small.  Especially
>> when run on localhost.
>
> The tests for amd64 were done using a 100mbit ethernet switch and two
> different pc's for client and server.

Ah, ok.  I've updated the wiki page to reflect this.  I ran the client
and server on the same machine.

/Simon




From nmav at gnutls.org  Mon Mar 10 13:01:47 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Mar 2008 14:01:47 +0200
Subject: Problems with certtool, version 1.2.10. Libgnutls 1.2.10
In-Reply-To: <200803071407.m27E7W4J009700@post.webmailer.de>
References: <200803071407.m27E7W4J009700@post.webmailer.de>
Message-ID: <47D5232B.4030308@gnutls.org>

armin gr?fe wrote:
> Hi there,
> 
> Sorry for bothering you, I didn't find meaningful information about the little issue I have using certtool.
>  I run a SLES10 (x86) and the command line that I entered was
> certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem
> 
> (as seen on http://www.linux-ha.org/QuorumServerGuide )
> Now the tool keeps telling me
> 
> The certificate will expire in (days): 1000
> Trailing garbage ignored: `
> '
> no matter what I enter (using either a GNOME terminal or a remote puTTY session).
> Can you give me a hint?

Check with your OS support for the problem you have in your console. 
Check also the
http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html#Invoking-certtool
to use certtool configuration file (so you avoid console).

regards,
Nikos




From simon at josefsson.org  Mon Mar 10 13:48:15 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 13:48:15 +0100
Subject: gnutls guile self checks fail: fport_fill_input
In-Reply-To: <8763vyak04.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 07
	Mar 2008 11:47:23 +0100")
References: <87lk4uoqg3.fsf@mocca.josefsson.org> <8763vyak04.fsf@gnu.org>
Message-ID: <873aqylp80.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi Simon,
>
> First of all, sorry for not being more involved...
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> jas at mocca:~/src/gnutls/guile/tests$ make check
>> make  check-TESTS
>> make[1]: Entering directory `/home/jas/src/gnutls/guile/tests'
>> ERROR: In procedure fport_fill_input:
>> ERROR: Is a directory
>> FAIL: anonymous-auth.scm
>> ...
>
> I can't reproduce the problem here with a copy of `master'.  Does
> `openpgp-auth.scm' (or other tests) fail similarly?  What platform is
> this on?

Yes, all guile checks fail this way.  Up-to-date x86 debian testing with
some packages from unstable.

>> I couldn't find these error message inside gnutls, so they could be
>> guile bugs, but I suspect you know better than me how to debug this.
>>
>> Strace shows something that may be related: it seems to open / but fails
>> because it is a directory.
>
> That seems to be the problem here: a Guile input port has been created
> for `/' and is being read from, which fails.  I can't find why this
> happens.
>
> Can you show the value of `$GUILE_LOAD_PATH' and all the `-L' switches
> passed to `guile' (see `guile/pre-inst-guile' and `TESTS_ENVIRONMENT' in
> `guile/tests/Makefile.am')?
>
> Can you also send me the whole `strace' output, if possible?

The pre-inst-guile file contains:

GUILE_LOAD_PATH="/home/jas/src/gnutls/guile/modules:$GUILE_LOAD_PATH"
export GUILE_LOAD_PATH

exec /home/jas/src/gnutls/libtool --mode=execute		                    \
       -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-v-1.la"        \
       -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-extra-v-1.la"  \
       /usr/bin/guile "$@"

I don't have a GUILE_LOAD_PATH in my environment.  The -L switch
evaluates to '-L .'.

I can reproduce it by:

jas at mocca:~/src/gnutls/guile/tests$ GUILE_LOAD_PATH="/home/jas/src/gnutls/guile/modules" /home/jas/src/gnutls/libtool --mode=execute                           -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-v-1.la"               -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-extra-v-1.la"        /usr/bin/guile -L . openpgp-auth.scm  
ERROR: In procedure fport_fill_input:
ERROR: Is a directory
jas at mocca:~/src/gnutls/guile/tests$ 

Could it be that I'm using libtool 2.2?  Yes, that seems to be the
problem, the following works:

jas at mocca:~/src/gnutls/guile/tests$ GUILE_LOAD_PATH="/home/jas/src/gnutls/guile/modules" /usr/bin/libtool --mode=execute                           -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-v-1.la"               -dlopen "/home/jas/src/gnutls/guile/src/libguile-gnutls-extra-v-1.la"        /usr/bin/guile -L . ./openpgp-auth.scm  jas at mocca:~/src/gnutls/guile/tests$ echo $?
0
jas at mocca:~/src/gnutls/guile/tests$ 

Running libtool with --debug reveals that it is interpreting the -L
parameter, so the command invoked will be:

+ eval exec '$cmd -L / /'
++ exec /usr/bin/guile -L / /
ERROR: In procedure fport_fill_input:
ERROR: Is a directory
jas at mocca:~/src/gnutls/guile/tests$ 

I think I should report this as a libtool bug.  What do you think?

/Simon




From ludo at gnu.org  Mon Mar 10 14:03:14 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 10 Mar 2008 14:03:14 +0100
Subject: gnutls guile self checks fail: fport_fill_input
References: <87lk4uoqg3.fsf@mocca.josefsson.org> <8763vyak04.fsf@gnu.org>
	<873aqylp80.fsf@mocca.josefsson.org>
Message-ID: <87lk4q3f59.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> Could it be that I'm using libtool 2.2?

Definitely.  ;-)  I'm using 1.5.26 here.

> Running libtool with --debug reveals that it is interpreting the -L
> parameter, so the command invoked will be:
>
> + eval exec '$cmd -L / /'
> ++ exec /usr/bin/guile -L / /

Conversely, I see this:

  + exec_cmd='$cmd "-L" "." "./anonymous-auth.scm"'
  + test -z '$cmd "-L" "." "./anonymous-auth.scm"'
  + test -n '$cmd "-L" "." "./anonymous-auth.scm"'
  + eval exec '$cmd' '"-L"' '"."' '"./anonymous-auth.scm"'
  ++ exec /home/ludo/soft/bin/guile -L . ./anonymous-auth.scm

> I think I should report this as a libtool bug.  What do you think?

Yes, that should be reported.

Is it really interpreting `-L'?  The `--debug' output you copied shows
that it *is* passing `-L', but the arguments to `-L' are mangled (where
does it get these two slashes from?).

Thanks,
Ludovic.





From simon at josefsson.org  Mon Mar 10 14:16:22 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 14:16:22 +0100
Subject: gnutls guile self checks fail: fport_fill_input
In-Reply-To: <87lk4q3f59.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon, 10
	Mar 2008 14:03:14 +0100")
References: <87lk4uoqg3.fsf@mocca.josefsson.org> <8763vyak04.fsf@gnu.org>
	<873aqylp80.fsf@mocca.josefsson.org> <87lk4q3f59.fsf@gnu.org>
Message-ID: <87od9mk9cp.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Could it be that I'm using libtool 2.2?
>
> Definitely.  ;-)  I'm using 1.5.26 here.
>
>> Running libtool with --debug reveals that it is interpreting the -L
>> parameter, so the command invoked will be:
>>
>> + eval exec '$cmd -L / /'
>> ++ exec /usr/bin/guile -L / /
>
> Conversely, I see this:
>
>   + exec_cmd='$cmd "-L" "." "./anonymous-auth.scm"'
>   + test -z '$cmd "-L" "." "./anonymous-auth.scm"'
>   + test -n '$cmd "-L" "." "./anonymous-auth.scm"'
>   + eval exec '$cmd' '"-L"' '"."' '"./anonymous-auth.scm"'
>   ++ exec /home/ludo/soft/bin/guile -L . ./anonymous-auth.scm
>
>> I think I should report this as a libtool bug.  What do you think?
>
> Yes, that should be reported.

Done, see:

http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/6070

> Is it really interpreting `-L'?  The `--debug' output you copied shows
> that it *is* passing `-L', but the arguments to `-L' are mangled (where
> does it get these two slashes from?).

It was easy to reproduce, see the bug report.  I don't understand the
behaviour.  Either it is a libtool bug or --mode=execute vs -L
interaction needs to be documented better.

Thanks,
/Simon




From simon at josefsson.org  Mon Mar 10 15:08:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 15:08:43 +0100
Subject: gnutls guile self checks fail: fport_fill_input
In-Reply-To: <87od9mk9cp.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 10 Mar 2008 14:16:22 +0100")
References: <87lk4uoqg3.fsf@mocca.josefsson.org> <8763vyak04.fsf@gnu.org>
	<873aqylp80.fsf@mocca.josefsson.org> <87lk4q3f59.fsf@gnu.org>
	<87od9mk9cp.fsf@mocca.josefsson.org>
Message-ID: <87zlt6isd0.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> Is it really interpreting `-L'?  The `--debug' output you copied shows
>> that it *is* passing `-L', but the arguments to `-L' are mangled (where
>> does it get these two slashes from?).
>
> It was easy to reproduce, see the bug report.  I don't understand the
> behaviour.  Either it is a libtool bug or --mode=execute vs -L
> interaction needs to be documented better.

It was a known libtool bug, sorry about the noise.  I've upgraded to
libtool trunk and will now release v2.3.3.

Thanks,
/Simon




From novel at FreeBSD.org  Mon Mar 10 15:32:39 2008
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Mon, 10 Mar 2008 17:32:39 +0300
Subject: gnutls 2.3.2 build fail because of opencdk
In-Reply-To: <871w6iomnx.fsf@mocca.josefsson.org>
References: <20080310092934.GA62715@underworld.novel.ru>
	<871w6iomnx.fsf@mocca.josefsson.org>
Message-ID: <20080310143238.GA66253@underworld.novel.ru>

  Simon Josefsson wrote:

> Roman Bogorodskiy <novel at FreeBSD.org> writes:
> 
> > When I try to build gnutls 2.3.2 without opencdk, it fails to build, the
> > log attached. It seems it fails because there's no
> > "-I$(top_srcdir)/lib/opencdk" flag in libextra/Makefile.am in
> > AM_CPPFLAGS variable. However, this problem won't show up on a system
> > with opencdk installed since it will pick opencdk.h from
> > /usr/local/include (or whatever standard include path on a system).
> >
> > Adding -I$(top_srcdir)/lib/opencdk to AM_CPPFLAGS in
> > libextra/Makefile.am solves the problem for me.
> 
> Thanks for the report.  That is a workaround, but the real fix was to
> remove libextra/gnutls_extra.h, as far as I could tell it is not needed
> any more.  Fixed in trunk, see:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=749abd0331001e05f82967a597552aa6f5db0563

Thanks for the quick fix and reply!

> Thanks,
> Simon

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: </pipermail/attachments/20080310/e20b9f1c/attachment.pgp>

From simon at josefsson.org  Mon Mar 10 15:37:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Mar 2008 15:37:07 +0100
Subject: GnuTLS 2.3.3
Message-ID: <87pru2ir1o.fsf@mocca.josefsson.org>

The GnuTLS 2.3.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

I tried to make sure there are no ABI/ABI modifications/deletions in
this compared to v2.2.x, but as the changes have been quite large, I may
have missed something.  Note that we don't guarantee ABI compatibility
during development releases, so if there are ABI breaks in this release,
we'll consider those bugs and revert them, rather than bumping the ABI.

Also, we need to figure out how the LGPL opencdk should be handled.  The
only LGPL'ed opencdk is the one included in this release.  There should
probably be an external release of this code.

News in this release:

* Version 2.3.3 (released 2008-03-10)

** Fix build failure in libextra/gnutls_extra.c that needed opencdk.h.
Reported by Roman Bogorodskiy <novel at FreeBSD.org>.

** No longer compiled using -D_REENTRANT -D_THREAD_SAFE.
We could not find any modern justification for enabling these flags by
default.  If you know of some platform that needs one of the flags to
work properly, please let us know.  (Actually introduced in v2.3.0 but
not documented until now.)

** Importing many CA certificates are now considerably faster.
This affect gnutls_certificate_set_x509_trust_mem,
gnutls_certificate_set_x509_trust, and
gnutls_certificate_set_x509_trust_file.  The complexity was reduced
From O(2*n^2) to O(n).  When adding 206 files containing 408
certificates, using gnutls_certificate_set_x509_trust_file, the time
dropped from 40 seconds to 0.3 seconds.  Thanks to Edgar Fu? for code
to trigger the problem.  See also
<http://blog.josefsson.org/2008/02/27/real-world-performance-tuning-with-callgrind/>.

** Clarify documentation for gnutls_x509_crt_set_subject_alternative_name
** to be explicit that it takes zero terminated data.

** gnutls-cli --print-cert now print PKCS#3 format Diffie-Hellman parameters.

** Documentation fixes for the GTK-DOC manual.

** Fix compilation error related to __FUNCTION__ on some systems.
Reported by Tim Mooney, see
<https://savannah.gnu.org/support/?106267>.

** Updated translations.

** Update gnulib files.

** API and ABI modifications:
gnutls_hex2bin: MODIFIED, uses size_t instead of int for string length,
		and char* instead of void* for output buffer.

The goals for the 2.3.x branch are tracked at:

http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.3.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.3.tar.bz2

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080310/403e8200/attachment.pgp>

From wk at gnupg.org  Tue Mar 11 17:09:19 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Mar 2008 17:09:19 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <87od9li6og.fsf@wheatstone.g10code.de>

On Sat,  8 Mar 2008 09:48, ametzler at downhill.at.eu.org said:

> but it looks like the mere presence of
> gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> causes the crashes.

That should be easy to debug:

  void
  _gcry_set_random_seed_file( const char *name )
  {
    if (seed_file_name)
      BUG ();
    seed_file_name = gcry_xstrdup (name);
  }

I guess you are running the init code twice.  Isn't there any output to
stderr?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From simon at josefsson.org  Tue Mar 11 20:57:35 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Mar 2008 20:57:35 +0100
Subject: openpgp stuff is gpl
Message-ID: <87od9l9gpc.fsf@mocca.josefsson.org>

Nikos, there are several openpgp-related files in lib/ which says the
license is GPL:

jas at mocca:~/src/gnutls/lib$ rgrep -l 'GNU Gene' *
gnutls_openpgp.c
opencdk/context.h
opencdk/Makefile.am
opencdk/types.h
opencdk/packet.h
opencdk/opencdk.h
opencdk/stream.h
opencdk/main.h
opencdk/filters.h
openpgp/privkey.c
openpgp/pgpverify.c
openpgp/Makefile.am
openpgp/pgp.c
openpgp/compat.c
openpgp/extras.c
jas at mocca:~/src/gnutls/lib$ 

Have these been properly re-licensed to LGPL?  If so, let me know or
push a license change on the files.

/Simon




From nmav at gnutls.org  Tue Mar 11 20:58:56 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Mar 2008 21:58:56 +0200
Subject: openpgp stuff is gpl
In-Reply-To: <87od9l9gpc.fsf@mocca.josefsson.org>
References: <87od9l9gpc.fsf@mocca.josefsson.org>
Message-ID: <47D6E480.2000408@gnutls.org>

Simon Josefsson wrote:
> Nikos, there are several openpgp-related files in lib/ which says the
> license is GPL:

> Have these been properly re-licensed to LGPL?  If so, let me know or
> push a license change on the files.

Yes, please do. Thank you.

Nikos




From simon at josefsson.org  Wed Mar 12 08:59:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Mar 2008 08:59:17 +0100
Subject: releasing LGPL version of opencdk?
Message-ID: <87zlt4cqzu.fsf@mocca.josefsson.org>

Timo, all,

I think we need to release a stand-alone version of the stripped down
opencdk under the LGPLv2 license.  The only problem appears to be the
name of that library.

Timo, do you want opencdk to continue be the name for your "complete"
package with all code?  If so, we have to rename the LGPLv2 version to
libminiopencdk, libopencdk-lite, libopencdk-gnutls, libgnutls-opencdk,
libgnutls-pgp or something similar (suggestions welcome).

Another option is to make the LGPLv2 code be the new "complete" version
of OpenCDK (and call it version 0.7.0).

I must admit that I don't really know what differs (which API functions)
between the complete opencdk and the stripped down copy.  I also do not
know if any package except GnuTLS really uses OpenCDK.  And in
particular whether they need the features present in the complete
package that are not present in the stripped down version.

I'd be happy to take the current lib/opencdk/ code in GnuTLS, write
autoconf magic for it, and release it as opencdk-lite.  That seems to be
the simplest way I can make things happen right now.

Ideas and thoughts very welcome.

/Simon




From wk at gnupg.org  Wed Mar 12 09:58:42 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Mar 2008 09:58:42 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <47D27B81.6060409@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 08 Mar 2008 13:41:53 +0200")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
Message-ID: <87myp4e2t9.fsf@wheatstone.g10code.de>

On Sat,  8 Mar 2008 12:41, nmav at gnutls.org said:

> So it seems libgcrypt is quite optimized in amd64... However there

Right, we have new optimized code for amd64 but the plain ia32 code is
pretty old and it might even be that the generic C implementation is
faster.

> with the small file). Possibly the RSA blinding...

I have a 10% performance penality for the blinding in mind.  Lets see:

$ ./benchmark --no-blinding rsa
Algorithm         generate  100*sign  100*verify
------------------------------------------------
RSA 1024 bit         390ms     890ms        20ms     680ms
RSA 2048 bit        2120ms    4220ms        80ms    4230ms

$ ./benchmark --no-blinding rsa
Algorithm         generate  100*sign  100*verify
------------------------------------------------
RSA 1024 bit         350ms     680ms        20ms     680ms
RSA 2048 bit        2110ms    4210ms        80ms    4230ms

$ ./benchmark --no-blinding rsa
Algorithm         generate  100*sign  100*verify
------------------------------------------------
RSA 1024 bit          60ms     710ms        30ms     660ms
RSA 2048 bit        1720ms    4230ms        80ms    4250ms


The last column is signing without blinding.  Except for the first test
(which is due to cache issues) I can't make out any difference.



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From simon at josefsson.org  Wed Mar 12 10:16:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Mar 2008 10:16:45 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87myp4e2t9.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Wed, 12 Mar 2008 09:58:42 +0100")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp4e2t9.fsf@wheatstone.g10code.de>
Message-ID: <87pru09u9u.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Sat,  8 Mar 2008 12:41, nmav at gnutls.org said:
>
>> So it seems libgcrypt is quite optimized in amd64... However there
>
> Right, we have new optimized code for amd64 but the plain ia32 code is
> pretty old and it might even be that the generic C implementation is
> faster.

Is that optimized MPI code?  Or AES?  I'll see if I can test with
--disable-asm in a live test.  We should also test non-RSA and non-AES
to see if we can pin-point what is slow.

>> with the small file). Possibly the RSA blinding...
>
> I have a 10% performance penality for the blinding in mind.  Lets see:

Doesn't openssl also do rsa blinding?

/Simon




From simon at josefsson.org  Wed Mar 12 10:58:00 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Mar 2008 10:58:00 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87pru09u9u.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 12 Mar 2008 10:16:45 +0100")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp4e2t9.fsf@wheatstone.g10code.de>
	<87pru09u9u.fsf@mocca.josefsson.org>
Message-ID: <87iqzsclhz.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Werner Koch <wk at gnupg.org> writes:
>
>> On Sat,  8 Mar 2008 12:41, nmav at gnutls.org said:
>>
>>> So it seems libgcrypt is quite optimized in amd64... However there
>>
>> Right, we have new optimized code for amd64 but the plain ia32 code is
>> pretty old and it might even be that the generic C implementation is
>> faster.
>
> Is that optimized MPI code?  Or AES?  I'll see if I can test with
> --disable-asm in a live test.  We should also test non-RSA and non-AES
> to see if we can pin-point what is slow.

I've added 3DES comparisons to:

http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/BenchmarkingModGnuTLSResults

3DES    mod_ssl small file: 310.78 trans/sec
3DES mod_gnutls small file: 154.77 trans/sec

3DES    mod_ssl large file: 7.25 trans/sec
3DES mod_gnutls large file: 5.75 trans/sec

Rather consistent with earlier ia32 results.  It is clear that 3DES is
quite slow on large data sizes.  AES-128 results:

AES    mod_ssl large file: 28.11 trans/sec
AES mod_gnutls large file: 15.25 trans/sec

For some reason I didn't get the DHE-DSS tests to work.  Perhaps I need
a DSA certificate.

/Simon




From simon at josefsson.org  Wed Mar 12 11:33:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Mar 2008 11:33:59 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87iqzsclhz.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 12 Mar 2008 10:58:00 +0100")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp4e2t9.fsf@wheatstone.g10code.de>
	<87pru09u9u.fsf@mocca.josefsson.org>
	<87iqzsclhz.fsf@mocca.josefsson.org>
Message-ID: <87ejagcju0.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> I've added 3DES comparisons to:
>
> http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/BenchmarkingModGnuTLSResults
>
> 3DES    mod_ssl small file: 310.78 trans/sec
> 3DES mod_gnutls small file: 154.77 trans/sec
>
> 3DES    mod_ssl large file: 7.25 trans/sec
> 3DES mod_gnutls large file: 5.75 trans/sec
>
> Rather consistent with earlier ia32 results.  It is clear that 3DES is
> quite slow on large data sizes.  AES-128 results:
>
> AES    mod_ssl large file: 28.11 trans/sec
> AES mod_gnutls large file: 15.25 trans/sec
>
> For some reason I didn't get the DHE-DSS tests to work.  Perhaps I need
> a DSA certificate.

Indeed, and I've updated the wiki pages with DSS testing information.
The results are consistent with gnutls having 50%-75% of openssl's
performance on ia32.  For TLS_DHE_DSS_WITH_RSA_128_CBC_SHA (0x0032):

   mod_ssl small file: 47.76 trans/sec
mod_gnutls small file: 34.13 trans/sec

   mod_ssl large file: 18.87 trans/sec
mod_gnutls large file: 11.60 trans/sec

However I just realized something important: OpenSSL in Debian have
CPU-specific optimizations.  Strace'ing apache indicates that it opens
libssl from /usr/lib/i686/ instead of /usr/lib/.  Libgcrypt is compiled
for i486 if I understand correctly.  That's not a fair comparison, so I
expect gnutls performance to be higher.

/Simon




From ametzler at downhill.at.eu.org  Wed Mar 12 20:20:44 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 12 Mar 2008 20:20:44 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <87od9li6og.fsf@wheatstone.g10code.de>
References: <87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87od9li6og.fsf@wheatstone.g10code.de>
Message-ID: <20080312192044.GA3513@downhill.g.la>

On 2008-03-11 Werner Koch <wk at gnupg.org> wrote:
> On Sat,  8 Mar 2008 09:48, ametzler at downhill.at.eu.org said:

> > but it looks like the mere presence of
> > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename)
> > causes the crashes.

> That should be easy to debug:

>   void
>   _gcry_set_random_seed_file( const char *name )
>   {
>     if (seed_file_name)
>       BUG ();
>     seed_file_name = gcry_xstrdup (name);
>   }

> I guess you are running the init code twice.  Isn't there any output to
> stderr?

Hello,
The exim daemon forks and closes stderr/out. Marc, can you try running
exim in the foreground and check whether gcrypt throws an error
(case GCRY_LOG_BUG:   fputs("Ohhhh jeeee: ", stderr); break;)?

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 from time to time, sure'




From mh+debian-bugs at zugschlus.de  Wed Mar 12 21:16:30 2008
From: mh+debian-bugs at zugschlus.de (Marc Haber)
Date: Wed, 12 Mar 2008 21:16:30 +0100
Subject: [Pkg-gnutls-maint] Bug#448775: Uses too much entropy (Debian
	Bug #343085)
In-Reply-To: <20080312192044.GA3513@downhill.g.la>
References: <87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
	<87od9li6og.fsf@wheatstone.g10code.de>
	<20080312192044.GA3513@downhill.g.la>
Message-ID: <20080312201630.GE20186@torres.zugschlus.de>

On Wed, Mar 12, 2008 at 08:20:44PM +0100, Andreas Metzler wrote:
> The exim daemon forks and closes stderr/out. Marc, can you try running
> exim in the foreground and check whether gcrypt throws an error
> (case GCRY_LOG_BUG:   fputs("Ohhhh jeeee: ", stderr); break;)?

Yes, it does.

$ sudo exim -bdf -q30m -oX 587:465:25 -oP /var/run/exim4/exim.pid
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)
Ohhhh jeeee: ... this is a bug (random.c:528:_gcry_set_random_seed_file)

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190




From wk at gnupg.org  Thu Mar 13 07:46:34 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Mar 2008 07:46:34 +0100
Subject: benchmarking mod_gnutls vs mod_ssl
In-Reply-To: <87pru09u9u.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 12 Mar 2008 10:16:45 +0100")
References: <87y78xi0ci.fsf@mocca.josefsson.org> <47D27B81.6060409@gnutls.org>
	<87myp4e2t9.fsf@wheatstone.g10code.de>
	<87pru09u9u.fsf@mocca.josefsson.org>
Message-ID: <87lk4nglyt.fsf@wheatstone.g10code.de>

On Wed, 12 Mar 2008 10:16, simon at josefsson.org said:

> Is that optimized MPI code?  Or AES?  I'll see if I can test with

Optimized MPI code (libgcrypt/mpi/amd64/), committed exactly a year ago.

> Doesn't openssl also do rsa blinding?

IIRC, OpenSSL also defaults to use RSA blinding.  But as shown, it is
not a performance issue.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From fweimer at bfk.de  Thu Mar 13 09:32:17 2008
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 13 Mar 2008 09:32:17 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <20080308084818.GC3091@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Mar 2008 09:48:18 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la>
Message-ID: <82fxuvyqge.fsf@mid.bfk.de>

* Andreas Metzler:

> we still seem have not been able to find a really working solution,
> this patch <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0>
> causes crashes in exim.

IIRC, I have already posted this, but perhaps my wording was a bit
unclear.

I don't think the seed file approach works for a forking daemon like
Exim because you cannot guaranteed an undisturbed read/modify/write
cycle on the seed file.  Locking is out of the question, too, because
it would bring the mail system to a standstill.  And it's arguably not
a good idea to reuse the same seed file in different forked children.

You need a separate daemon, or trust the kernel and read fewer bytes
from /dev/urandom.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




From wk at gnupg.org  Thu Mar 13 13:55:47 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Mar 2008 13:55:47 +0100
Subject: Bug#448775: Uses too much entropy (Debian Bug #343085)
In-Reply-To: <82fxuvyqge.fsf@mid.bfk.de> (Florian Weimer's message of "Thu, 13
	Mar 2008 09:32:17 +0100")
References: <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de>
	<87fxxdbw59.fsf@mocca.josefsson.org>
	<87r6gx4sdf.fsf@wheatstone.g10code.de>
	<87tzltr7za.fsf@mocca.josefsson.org>
	<87k5mp385s.fsf@wheatstone.g10code.de>
	<8763y9r35b.fsf@mocca.josefsson.org>
	<87wsqk4pf6.fsf@wheatstone.g10code.de>
	<20080130182010.GA5173@downhill.g.la>
	<87fxwe4d0g.fsf@wheatstone.g10code.de>
	<20080308084818.GC3091@downhill.g.la> <82fxuvyqge.fsf@mid.bfk.de>
Message-ID: <871w6eg4vg.fsf@wheatstone.g10code.de>

On Thu, 13 Mar 2008 09:32, fweimer at bfk.de said:

> I don't think the seed file approach works for a forking daemon like
> Exim because you cannot guaranteed an undisturbed read/modify/write
> cycle on the seed file.  Locking is out of the question, too, because

It depends on how much entropy you want to have in the pool.  Even with
all processes using the same random seed, libgcrypt will add extra
random to each process (e.g. 16 bytes from /dev/urandom).  This turns it
into a PRNG which is not worse than using /dev/urandom directly.

The advantage reading a the seed file is that libgcrypt does not need to
initialize its own random pool.  You may view this initialization as
assuring that the random pool is not plain zeroed out.

If you don't like that approach you cat limit the reuse of the seed file
by using a seed file name depending on the pid, like
 asprintf ("/foo/bar/andom_seed.%d", ((int)getpid() % 5))


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From nmav at gnutls.org  Sun Mar 16 17:47:31 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 16 Mar 2008 18:47:31 +0200
Subject: basics for cryptodev support
Message-ID: <47DD4F23.20709@gnutls.org>

I'm working slowly into adding some support for hw crypto devices. 
Currently the easiest way to achieve this is by using the kernel crypto 
hw support (in linux there is already support for via and geode aes 
implementations and there is also ocf-linux[0] which provides more hw).

For this reason I added an API to register ciphers and macs (rnd + pki 
will follow on my next burst).

Initially to test this support I'll need to add support for /dev/crypto 
when it is available (freebsd/openbsd, linux with ocf).

If anyone is interested in helping in any of these, please contact me.

The current API to register ciphers and hash/hmac is:

typedef struct gnutls_crypto_cipher {
   int (*init)( void** ctx);
   int (*setkey)( void* ctx, const void * key, int keysize);
   int (*setiv)(void* ctx, const void* iv, int ivsize);
   int (*encrypt)(void* ctx, const void* plain, int plainsize, void* 
encr, int encrsize);
   int (*decrypt)(void* ctx, const void* encr, int encrsize, void* 
plain, int plainsize);
   void (*deinit)( void* ctx);
} gnutls_crypto_cipher_st;

typedef struct gnutls_crypto_mac {
   int (*init)( void** ctx);
   int (*setkey)( void* ctx, const void * key, int keysize);
   int (*hash)( void* ctx, const void * text, int textsize);
   int (*copy)( void** dst_ctx, void* src_ctx);
   int (*output) ( void* src_ctx, void* digest, int digestsize);
   void (*deinit)( void* ctx);
} gnutls_crypto_mac_st;

/* the same... setkey should be null */
typedef gnutls_crypto_mac_st gnutls_crypto_digest_st;

int gnutls_crypto_cipher_register( gnutls_cipher_algorithm_t algorithm, 
int priority, gnutls_crypto_cipher_st* s);
int gnutls_crypto_mac_register( gnutls_mac_algorithm_t algorithm, int 
priority, gnutls_crypto_mac_st* s);
int gnutls_crypto_digest_register( gnutls_digest_algorithm_t algorithm, 
int priority, gnutls_crypto_digest_st* s)


[0]. http://ocf-linux.sourceforge.net/


regards,
Nikos




From simon at josefsson.org  Wed Mar 19 13:49:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 13:49:58 +0100
Subject: basics for cryptodev support
In-Reply-To: <47DD4F23.20709@gnutls.org> (Nikos Mavrogiannopoulos's message of
	"Sun, 16 Mar 2008 18:47:31 +0200")
References: <47DD4F23.20709@gnutls.org>
Message-ID: <87od9azxmx.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> I'm working slowly into adding some support for hw crypto
> devices. Currently the easiest way to achieve this is by using the
> kernel crypto hw support (in linux there is already support for via
> and geode aes implementations and there is also ocf-linux[0] which
> provides more hw).

Cool!

> For this reason I added an API to register ciphers and macs

Will this API be stable?  I'd like to push out a stable 2.4.0 in a few
weeks.  If there is any risk that this API will change during 2.5.x, I
think we should revert this change and add it for the next development
cycle instead.

>(rnd + pki will follow on my next burst).

When I migrated the code to use gnulib for low-level crypto, I gave up
on mpi stuff, since it was rather libgcrypt-specific right now.
Finishing this would be really great.

/Simon

> Initially to test this support I'll need to add support for
> /dev/crypto when it is available (freebsd/openbsd, linux with ocf).
>
> If anyone is interested in helping in any of these, please contact me.
>
> The current API to register ciphers and hash/hmac is:
>
> typedef struct gnutls_crypto_cipher {
>   int (*init)( void** ctx);
>   int (*setkey)( void* ctx, const void * key, int keysize);
>   int (*setiv)(void* ctx, const void* iv, int ivsize);
>   int (*encrypt)(void* ctx, const void* plain, int plainsize, void*
> encr, int encrsize);
>   int (*decrypt)(void* ctx, const void* encr, int encrsize, void*
> plain, int plainsize);
>   void (*deinit)( void* ctx);
> } gnutls_crypto_cipher_st;
>
> typedef struct gnutls_crypto_mac {
>   int (*init)( void** ctx);
>   int (*setkey)( void* ctx, const void * key, int keysize);
>   int (*hash)( void* ctx, const void * text, int textsize);
>   int (*copy)( void** dst_ctx, void* src_ctx);
>   int (*output) ( void* src_ctx, void* digest, int digestsize);
>   void (*deinit)( void* ctx);
> } gnutls_crypto_mac_st;
>
> /* the same... setkey should be null */
> typedef gnutls_crypto_mac_st gnutls_crypto_digest_st;
>
> int gnutls_crypto_cipher_register( gnutls_cipher_algorithm_t
> algorithm, int priority, gnutls_crypto_cipher_st* s);
> int gnutls_crypto_mac_register( gnutls_mac_algorithm_t algorithm, int
> priority, gnutls_crypto_mac_st* s);
> int gnutls_crypto_digest_register( gnutls_digest_algorithm_t
> algorithm, int priority, gnutls_crypto_digest_st* s)
>
>
> [0]. http://ocf-linux.sourceforge.net/
>
>
> regards,
> Nikos




From simon at josefsson.org  Wed Mar 19 14:04:15 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 14:04:15 +0100
Subject: releasing LGPL version of opencdk?
In-Reply-To: <47D7AE54.4090706@gmx.net> (Timo Schulz's message of "Wed, 12 Mar
	2008 11:20:04 +0100")
References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net>
Message-ID: <87k5jyx3u8.fsf@mocca.josefsson.org>

(Quoting liberally to preserve mailing list archive context..)

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> Timo, do you want opencdk to continue be the name for your "complete"
>> package with all code?  If so, we have to rename the LGPLv2 version to
>> libminiopencdk, libopencdk-lite, libopencdk-gnutls, libgnutls-opencdk,
>> libgnutls-pgp or something similar (suggestions welcome).
>
> For the next 1-2 years it is very unlikely that I will find the time
> to maintain or adjust the library. In other words, to work on important
> issues and to fix all the existing problems....
>
>> Another option is to make the LGPLv2 code be the new "complete" version
>> of OpenCDK (and call it version 0.7.0).
>
> ...therefore I would say that it is the best idea to rename the
> LGPL library to libopencdk-gnutls.
>
>> between the complete opencdk and the stripped down copy.  I also do not
>> know if any package except GnuTLS really uses OpenCDK.
>
> Not any popular package I'm aware of.
>
>
>> I'd be happy to take the current lib/opencdk/ code in GnuTLS, write
>> autoconf magic for it, and release it as opencdk-lite.  That seems to be
>> the simplest way I can make things happen right now.
>
> I agree. Plus, the GnuTLS team can adjust the library so it better
> fits the requirements for TLS and remove other code which is not
> required.
>
>
> I really wish I would have more time, because large parts of the library
> either needs to be revamped or rewritten. With the libopencdk-gnutls
> decision we can at least assure, that the openpgp support for GnuTLS
> is up-to-date and maintained.

Ok, great.  I'll do a release of it and make gnutls depend on it.

Regarding naming, on second thought, I think it would be better to avoid
having 'gnutls' in the name of the LGPL package since it would be
confusing if any non-gnutls projects to link with it.
'libopencdk-lite'?

/Simon




From simon at josefsson.org  Wed Mar 19 14:06:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 14:06:58 +0100
Subject: GnuTLS 2.3.4
Message-ID: <87fxumx3pp.fsf@mocca.josefsson.org>

The GnuTLS 2.3.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

My next step is to release a libopencdk-lite, then make a gnutls 2.3.5
that use it, then branch off gnutls_2_4_x and go for a new stable GnuTLS
release in a few weeks.

I tried to make sure there are no ABI/ABI modifications/deletions in
this compared to v2.2.x, but as the changes have been quite large, I may
have missed something.  Note that we don't guarantee ABI compatibility
during development releases, so if there are ABI breaks in this release,
we'll consider those bugs and revert them, rather than bumping the ABI.

Also, we need to figure out how the LGPL opencdk should be handled.  The
only LGPL'ed opencdk is the one included in this release.  There should
probably be an external release of this code.

News in this release:

* Version 2.3.4 (released 2008-03-19)

** Finish renaming of gnutls_certificate_export_x509_cas etc.
They weren't renamed in the public header file.

** Added functions to register a cipher/mac/digest. This allows to 
override the included ones.

** Fix a bunch of compiler warnings.

** API and ABI modifications:
gnutls_crypto_cipher_st: ADDED
gnutls_crypto_mac_st: ADDED
gnutls_crypto_digest_st: ADDED
gnutls_crypto_cipher_register: ADDED
gnutls_crypto_mac_register: ADDED
gnutls_crypto_digest_register: ADDED
GNUTLS_E_CRYPTO_ALREADY_REGISTERED: ADDED

The goals for the 2.3.x branch are tracked at:

http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.tar.bz2

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon




From nmav at gnutls.org  Wed Mar 19 19:28:14 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 19 Mar 2008 20:28:14 +0200
Subject: releasing LGPL version of opencdk?
In-Reply-To: <87k5jyx3u8.fsf@mocca.josefsson.org>
References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net>
	<87k5jyx3u8.fsf@mocca.josefsson.org>
Message-ID: <47E15B3E.8080005@gnutls.org>

Simon Josefsson wrote:

> Regarding naming, on second thought, I think it would be better to avoid
> having 'gnutls' in the name of the LGPL package since it would be
> confusing if any non-gnutls projects to link with it.
> 'libopencdk-lite'?

I also like the lite version better :)


regards,
Nikos




From twoaday at gmx.net  Wed Mar 19 19:38:54 2008
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 19 Mar 2008 19:38:54 +0100
Subject: releasing LGPL version of opencdk?
In-Reply-To: <47E15B3E.8080005@gnutls.org>
References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net>
	<87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org>
Message-ID: <47E15DBE.20005@gmx.net>

Nikos Mavrogiannopoulos wrote:
> Simon Josefsson wrote:
> 
>> Regarding naming, on second thought, I think it would be better to avoid
>> having 'gnutls' in the name of the LGPL package since it would be
>> confusing if any non-gnutls projects to link with it.
>> 'libopencdk-lite'?
> 
> I also like the lite version better :)

I've to agree, that the 'gnutls' part might confuse user.
So it's settled, we use the 'libopencdk-lite' name :-).


	Timo




From simon at josefsson.org  Wed Mar 19 22:08:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 22:08:26 +0100
Subject: GnuTLS 2.3.4 error in gnutls_extra.c with --with-lzo
In-Reply-To: <47E1770E.4010404@enterprise.bidmc.harvard.edu> (Kristofer
	T. Karas's message of "Wed, 19 Mar 2008 16:26:54 -0400")
References: <47E1770E.4010404@enterprise.bidmc.harvard.edu>
Message-ID: <87ve3iqv5h.fsf@mocca.josefsson.org>

"Kristofer T. Karas" <ktk at enterprise.bidmc.harvard.edu> writes:

> Hello,
>
> Just wanted to report a build error in the most recent 2.3.4 version
> of gnutls:
>
> 	libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I/usr/include -pipe -g -O2 -Wno-pointer-sign -MT gnutls_extra.lo -MD -MP -MF .deps/gnutls_extra.Tpo -c gnutls_extra.c  -fPIC -DPIC -o .libs/gnutls_extra.o
> 	gnutls_extra.c: In function 'gnutls_global_init_extra':
> 	gnutls_extra.c:127: error: 'ret' undeclared (first use in this function)
>
>
> This occurs with three different Linux systems with three different
> versions of gcc (3.3.6, 3.4.6, 4.2.3), glibc (2.3.5, 2.3.6, 2.7) and
> autoconf (2.59, 2.60, 2.61), so it doesn't appear to be
> platform-specific as far as I can tell.  The configure line used in
> all three cases was:
>
> 	./configure --with-lzo --build=i686-slackware-linux-gnu --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --localstatedir=/var --mandir=/usr/man --infodir=/usr/info
>
> Tracking this down a bit, the error only seems to occur when
> "--with-lzo" is given to ./configure.  (I have lzo-2.02 installed in
> the normal /usr/lib location.)

Ah, it seems I don't test LZO enabled anymore.  I've installed the
following patch on the trunk, thanks!

/Simon

commit 45af721c79dad46ba60e1fc75911ebe7fc1ce25f
Author: Simon Josefsson <simon at josefsson.org>
Date:   Wed Mar 19 22:03:55 2008 +0100

    Fix LZO build failure.

diff --git a/libextra/gnutls_extra.c b/libextra/gnutls_extra.c
index bf81a50..970208e 100644
--- a/libextra/gnutls_extra.c
+++ b/libextra/gnutls_extra.c
@@ -116,20 +116,24 @@ gnutls_global_init_extra (void)
   /* Initialize the LZO library
    */
 #ifdef USE_LZO
-  if (lzo_init () != LZO_E_OK)
-    {
-      return GNUTLS_E_LZO_INIT_FAILED;
-    }
-
-  /* Add the LZO compression method in the list of compression
-   * methods.
-   */
-  ret = _gnutls_add_lzo_comp ();
-  if (ret < 0)
-    {
-      gnutls_assert ();
-      return ret;
-    }
+  {
+    int ret;
+
+    if (lzo_init () != LZO_E_OK)
+      {
+	return GNUTLS_E_LZO_INIT_FAILED;
+      }
+
+    /* Add the LZO compression method in the list of compression
+     * methods.
+     */
+    ret = _gnutls_add_lzo_comp ();
+    if (ret < 0)
+      {
+	gnutls_assert ();
+	return ret;
+      }
+  }
 #endif
 
   return 0;




From nmav at gnutls.org  Thu Mar 20 18:11:12 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Mar 2008 19:11:12 +0200
Subject: basics for cryptodev support
In-Reply-To: <87od9azxmx.fsf@mocca.josefsson.org>
References: <47DD4F23.20709@gnutls.org> <87od9azxmx.fsf@mocca.josefsson.org>
Message-ID: <47E29AB0.1080104@gnutls.org>

Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
>> I'm working slowly into adding some support for hw crypto
>> devices. Currently the easiest way to achieve this is by using the
>> kernel crypto hw support (in linux there is already support for via
>> and geode aes implementations and there is also ocf-linux[0] which
>> provides more hw).
> 
> Cool!
> 
>> For this reason I added an API to register ciphers and macs
> 
> Will this API be stable?  I'd like to push out a stable 2.4.0 in a few
> weeks.  If there is any risk that this API will change during 2.5.x, I
> think we should revert this change and add it for the next development
> cycle instead.

No I wouldn't consider them stable since I need to test them first with 
some other crypto provider (say cryptodev). I also haven't finished it 
(rnd and pki remain to be done).

>> (rnd + pki will follow on my next burst).

> When I migrated the code to use gnulib for low-level crypto, I gave up
> on mpi stuff, since it was rather libgcrypt-specific right now.
> Finishing this would be really great.

I've also gave up several times after starting this. I'll try to work on 
it the next 2-3 weeks.

regards,
Nikos




From joe at manyfish.co.uk  Fri Mar 28 22:41:41 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 28 Mar 2008 21:41:41 +0000
Subject: 2.3.x regression in auth_cert.c:call_get_cert_callback
Message-ID: <20080328214141.GA6945@manyfish.co.uk>

The test case in the neon test suite for neon's PKCS#11 interface is 
broken with 2.3.4; it works with earlier versions (at least 2.3.0, 
haven't tested the version in between).

In the test case, neon provides callbacks via both
 
a) gnutls_certificate_client_set_retrieve_function and
b) gnutls_sign_callback_set 

The callback for (a) finds a keypair via a configured PKCS#11 provider, 
and sets up st->cert.x509 et al as normal; st->key.x509 is set to NULL, 
since the callback for (b) is used to delegate the signing operation via 
PKCS#11.

GnuTLS now fails if st->key.x509 is NULL; if I avoid that code path as 
below, it works again.  Is this not the correct way to be using the 
interface?  There is nothing much else that could be returned in 
key.x509 for this case, AFAICS.

diff -up ./lib/auth_cert.c.unbreak ./lib/auth_cert.c
--- ./lib/auth_cert.c.unbreak	2008-03-10 15:02:35.000000000 +0000
+++ ./lib/auth_cert.c	2008-03-28 21:31:57.000000000 +0000
@@ -456,7 +456,7 @@ call_get_cert_callback (gnutls_session_t
   if (type == GNUTLS_CRT_X509)
     {
       local_certs = alloc_and_load_x509_certs (st.cert.x509, st.ncerts);
-      if (local_certs != NULL) 
+      if (local_certs != NULL && st.key.x509 != NULL) 
         {
 	  local_key = alloc_and_load_x509_key (st.key.x509);
  	  if (local_key == NULL)




From nmav at gnutls.org  Sat Mar 29 11:08:46 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Mar 2008 12:08:46 +0200
Subject: 2.3.x regression in auth_cert.c:call_get_cert_callback
In-Reply-To: <20080328214141.GA6945@manyfish.co.uk>
References: <20080328214141.GA6945@manyfish.co.uk>
Message-ID: <47EE152E.4010402@gnutls.org>

Joe Orton wrote:
> The test case in the neon test suite for neon's PKCS#11 interface is 
> broken with 2.3.4; it works with earlier versions (at least 2.3.0, 
> haven't tested the version in between).
> 
> In the test case, neon provides callbacks via both
>  
> a) gnutls_certificate_client_set_retrieve_function and
> b) gnutls_sign_callback_set 
> 
> The callback for (a) finds a keypair via a configured PKCS#11 provider, 
> and sets up st->cert.x509 et al as normal; st->key.x509 is set to NULL, 
> since the callback for (b) is used to delegate the signing operation via 
> PKCS#11.
> 
> GnuTLS now fails if st->key.x509 is NULL; if I avoid that code path as 
> below, it works again.  Is this not the correct way to be using the 
> interface?  There is nothing much else that could be returned in 
> key.x509 for this case, AFAICS.

You're right. I've reverted to the old behaviour.

regards,
Nikos




From cmaiku at gmail.com  Mon Mar 31 09:14:58 2008
From: cmaiku at gmail.com (Maiku)
Date: Mon, 31 Mar 2008 02:14:58 -0500
Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH
Message-ID: <e39899ed0803310014w45d3813agfe05775cda4568ea@mail.gmail.com>

I discovered that if you try to connect to login.live.com with GNU TLS (I
used gnutls-cli) and send any data to it, after a successful connection,
when it gets to the end of receiving a response to that data, it throws a
GNUTLS_E_UNEXPECTED_PACKET_LENGTH error. I tried the same test on another
SSL server (addons.mozilla.org) and it worked fine, so I imagine it's
something that login.live.com is doing specifically. I tested it with the
version of GNU TLS that comes with Ubuntu 7.10, 8.04 beta, and the
2.3.4source package from the GNU TLS site, and all of them had the
same results.

I went digging through the code and found that the problem seems to be in
gnutls_record.c in the function _gnutls_recv_int on line 899 (at least
that's the line in version 2.3.4). The line reads:

   if (ret < 0 && gnutls_error_is_fatal (ret) == 0)

I believe this should be changed to:

   if (gnutls_error_is_fatal (ret) == 0)

because the a return value of zero is not fatal, but as the code currently
reads it doesn't return (as I think it should).

I tried it and the change seemed to remedy my problem. I'm happy to
formalize a patch for it. Although I'm not not sure which format it should
be in, where to send it to, or if this post is sufficient.

Maiku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080331/aa3a8d3c/attachment.htm>

From joe at manyfish.co.uk  Mon Mar 31 11:38:55 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Mon, 31 Mar 2008 10:38:55 +0100
Subject: 2.3.x regression in auth_cert.c:call_get_cert_callback
In-Reply-To: <47EE152E.4010402@gnutls.org>
References: <20080328214141.GA6945@manyfish.co.uk>
	<47EE152E.4010402@gnutls.org>
Message-ID: <20080331093855.GA30265@manyfish.co.uk>

On Sat, Mar 29, 2008 at 12:08:46PM +0200, Nikos Mavrogiannopoulos wrote:
> Joe Orton wrote:
>> GnuTLS now fails if st->key.x509 is NULL; if I avoid that code path as 
>> below, it works again.  Is this not the correct way to be using the 
>> interface?  There is nothing much else that could be returned in key.x509 
>> for this case, AFAICS.
>
> You're right. I've reverted to the old behaviour.

Thanks.  With this applied and the new DN functions in 2.3.x, the last 
of the neon regressions relative to OpenSSL are now fixed and for the 
first time I get a 100% pass rate with neon's SSL test suite.  And due 
to the external signing callback in GnuTLS, neon supports one major 
feature which is not supported with OpenSSL - PKCS#11.

So, nice work, guys :)

joe
-------------- next part --------------
make[1]: Entering directory `/local/neon/neon-gnutls/src'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/local/neon/neon-gnutls/src'
make[1]: Entering directory `/local/neon/neon-gnutls/test'
-> running `ssl':
 0. init.................. pass
 1. load_server_certs..... pass
 2. trust_default_ca...... pass
 3. cert_fingerprint...... pass
 4. cert_identities....... pass
 5. cert_validity......... pass
 6. cert_compare.......... pass
 7. dname_compare......... pass
 8. dname_readable........ pass
 9. import_export......... pass
10. read_write............ pass
11. load_client_cert...... WARNING: no friendly name given
    ...................... pass (with 1 warning)
12. simple................ pass
13. simple_sslv2.......... pass
14. simple_eof............ pass
15. empty_truncated_eof... pass
16. fail_not_ssl.......... pass
17. cache_cert............ pass
18. client_cert_pkcs12.... pass
19. ccert_unencrypted..... pass
20. client_cert_provided.. pass
21. cc_provided_dnames.... pass
22. parse_cert............ pass
23. parse_chain........... pass
24. no_verify............. pass
25. cache_verify.......... pass
26. wildcard_match........ pass
27. caseless_match........ pass
28. subject_altname....... pass
29. two_subject_altname... pass
30. two_subject_altname2.. pass
31. notdns_altname........ pass
32. ipaddr_altname........ pass
33. uri_altname........... pass
34. multi_commonName...... pass
35. commonName_first...... pass
36. fail_wrongCN.......... pass
37. fail_expired.......... pass
38. fail_notvalid......... pass
39. fail_untrusted_ca..... pass
40. fail_self_signed...... pass
41. fail_missing_CN....... pass
42. fail_host_ipaltname... pass
43. fail_bad_ipaltname.... pass
44. fail_bad_urialtname... pass
45. session_cache......... pass
46. fail_tunnel........... pass
47. proxy_tunnel.......... pass
48. auth_proxy_tunnel..... pass
49. auth_tunnel_creds..... pass
50. auth_tunnel_fail...... pass
51. nonssl_trust.......... pass
52. pkcs11................ pass
53. pkcs11_dsa............ server child failed: SSL accept failed: SSL error: The scanning of a large integer has failed.
xfail
<- summary for `ssl': of 54 tests run: 54 passed, 0 failed. 100.0%
-> 1 warning was issued.
make[1]: Leaving directory `/local/neon/neon-gnutls/test'

From simon at josefsson.org  Mon Mar 31 12:28:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Mar 2008 12:28:29 +0200
Subject: 2.3.x regression in auth_cert.c:call_get_cert_callback
In-Reply-To: <20080331093855.GA30265@manyfish.co.uk> (Joe Orton's message of
	"Mon, 31 Mar 2008 10:38:55 +0100")
References: <20080328214141.GA6945@manyfish.co.uk>
	<47EE152E.4010402@gnutls.org> <20080331093855.GA30265@manyfish.co.uk>
Message-ID: <878wzzyype.fsf@mocca.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> On Sat, Mar 29, 2008 at 12:08:46PM +0200, Nikos Mavrogiannopoulos wrote:
>> Joe Orton wrote:
>>> GnuTLS now fails if st->key.x509 is NULL; if I avoid that code path as 
>>> below, it works again.  Is this not the correct way to be using the 
>>> interface?  There is nothing much else that could be returned in key.x509 
>>> for this case, AFAICS.
>>
>> You're right. I've reverted to the old behaviour.
>
> Thanks.  With this applied and the new DN functions in 2.3.x, the last 
> of the neon regressions relative to OpenSSL are now fixed and for the 
> first time I get a 100% pass rate with neon's SSL test suite.  And due 
> to the external signing callback in GnuTLS, neon supports one major 
> feature which is not supported with OpenSSL - PKCS#11.
>
> So, nice work, guys :)

Cool!  Can I build and run the neon self test suite relatively easy
myself?  It seems it checks a lot TLS stuff, and it might be useful to
run before releasing v2.4.0 to catch silly mistakes.

> 11. load_client_cert...... WARNING: no friendly name given
>     ...................... pass (with 1 warning)
...
> 53. pkcs11_dsa............ server child failed: SSL accept failed: SSL error: The scanning of a large integer has failed.

Does this refer to anything we should improve in gnutls?

/Simon




From simon at josefsson.org  Mon Mar 31 12:46:10 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Mar 2008 12:46:10 +0200
Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH
In-Reply-To: <e39899ed0803310014w45d3813agfe05775cda4568ea@mail.gmail.com>
	(Maiku's message of "Mon, 31 Mar 2008 02:14:58 -0500")
References: <e39899ed0803310014w45d3813agfe05775cda4568ea@mail.gmail.com>
Message-ID: <874panyxvx.fsf@mocca.josefsson.org>

Maiku <cmaiku at gmail.com> writes:

> I discovered that if you try to connect to login.live.com with GNU TLS (I
> used gnutls-cli) and send any data to it, after a successful connection,
> when it gets to the end of receiving a response to that data, it throws a
> GNUTLS_E_UNEXPECTED_PACKET_LENGTH error. I tried the same test on another
> SSL server (addons.mozilla.org) and it worked fine, so I imagine it's
> something that login.live.com is doing specifically. I tested it with the
> version of GNU TLS that comes with Ubuntu 7.10, 8.04 beta, and the
> 2.3.4source package from the GNU TLS site, and all of them had the
> same results.

Thanks for the report.  I believe the server is buggy, it disconnects
instead of sending a CLOSE alert after the HTTP command has completed.
GnuTLS expects a TLS header at that point, but gets no data at all,
hence the unexpected length error.

I'm not sure what the proper behaviour should be.  I don't think
ignoring this error condition is a good idea, it makes the
implementation vulnerable to the same problem that SSLv2 were vulnerable
to.  (I.e., faking TCP FIN makes recipient believe the TLS channel is
terminated successfully.)

The error message isn't particularly helpful.  We could add another
error code, such as GNUTLS_E_PREMATURE_CLOSE or similar instead.  What
do you think?

> I went digging through the code and found that the problem seems to be in
> gnutls_record.c in the function _gnutls_recv_int on line 899 (at least
> that's the line in version 2.3.4). The line reads:
>
>    if (ret < 0 && gnutls_error_is_fatal (ret) == 0)
>
> I believe this should be changed to:
>
>    if (gnutls_error_is_fatal (ret) == 0)
>
> because the a return value of zero is not fatal, but as the code currently
> reads it doesn't return (as I think it should).

I believe this patch would ignore the error condition, which is a bad
idea.

> I tried it and the change seemed to remedy my problem. I'm happy to
> formalize a patch for it. Although I'm not not sure which format it should
> be in, where to send it to, or if this post is sufficient.

Posting to this list is the best way to do it.

/Simon




From joe at manyfish.co.uk  Mon Mar 31 12:47:29 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Mon, 31 Mar 2008 11:47:29 +0100
Subject: 2.3.x regression in auth_cert.c:call_get_cert_callback
In-Reply-To: <878wzzyype.fsf@mocca.josefsson.org>
References: <20080328214141.GA6945@manyfish.co.uk>
	<47EE152E.4010402@gnutls.org>
	<20080331093855.GA30265@manyfish.co.uk>
	<878wzzyype.fsf@mocca.josefsson.org>
Message-ID: <20080331104729.GA30746@manyfish.co.uk>

On Mon, Mar 31, 2008 at 12:28:29PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> > Thanks.  With this applied and the new DN functions in 2.3.x, the last 
> > of the neon regressions relative to OpenSSL are now fixed and for the 
> > first time I get a 100% pass rate with neon's SSL test suite.  And due 
> > to the external signing callback in GnuTLS, neon supports one major 
> > feature which is not supported with OpenSSL - PKCS#11.
> >
> > So, nice work, guys :)
> 
> Cool!  Can I build and run the neon self test suite relatively easy
> myself?  It seems it checks a lot TLS stuff, and it might be useful to
> run before releasing v2.4.0 to catch silly mistakes.

svn co http://svn.webdav.org/repos/projects/neon/trunk/
cd trunk
./autogen.sh
./configure --with-ssl=gnutls --with-libs=/path/to/gnutls/install/root
make check TESTS=ssl

should be sufficient; let me know if not.

You need to have pakchois (http://www.manyfish.co.uk/pakchois/) and NSS 
installed in standard places to be able to test the PKCS#11 interfaces; 
the test suite uses the NSS software token.

> > 11. load_client_cert...... WARNING: no friendly name given
> >     ...................... pass (with 1 warning)
> ...
> > 53. pkcs11_dsa............ server child failed: SSL accept failed: SSL error: The scanning of a large integer has failed.
> 
> Does this refer to anything we should improve in gnutls?

For 11, possibly yes - OpenSSL allows you to retrieve the friendly name 
of an encrypted PKCS#12 cert without decrypting it; I couldn't work out 
how do to that with GnuTLS.

For 53, I don't know, I haven't looked into this yet, I suspect it's a 
bug in neon or the neon test suite (hence the test is marked as expected 
to fail).

joe





From joe at manyfish.co.uk  Mon Mar 31 15:01:13 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Mon, 31 Mar 2008 14:01:13 +0100
Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH
In-Reply-To: <874panyxvx.fsf@mocca.josefsson.org>
References: <e39899ed0803310014w45d3813agfe05775cda4568ea@mail.gmail.com>
	<874panyxvx.fsf@mocca.josefsson.org>
Message-ID: <20080331130113.GA31656@manyfish.co.uk>

On Mon, Mar 31, 2008 at 12:46:10PM +0200, Simon Josefsson wrote:
> Maiku <cmaiku at gmail.com> writes:
> 
> > I discovered that if you try to connect to login.live.com with GNU TLS (I
> > used gnutls-cli) and send any data to it, after a successful connection,
> > when it gets to the end of receiving a response to that data, it throws a
> > GNUTLS_E_UNEXPECTED_PACKET_LENGTH error. I tried the same test on another
> > SSL server (addons.mozilla.org) and it worked fine, so I imagine it's
> > something that login.live.com is doing specifically. I tested it with the
> > version of GNU TLS that comes with Ubuntu 7.10, 8.04 beta, and the
> > 2.3.4source package from the GNU TLS site, and all of them had the
> > same results.
> 
> Thanks for the report.  I believe the server is buggy, it disconnects
> instead of sending a CLOSE alert after the HTTP command has completed.
> GnuTLS expects a TLS header at that point, but gets no data at all,
> hence the unexpected length error.
> 
> I'm not sure what the proper behaviour should be.  I don't think
> ignoring this error condition is a good idea, it makes the
> implementation vulnerable to the same problem that SSLv2 were vulnerable
> to.  (I.e., faking TCP FIN makes recipient believe the TLS channel is
> terminated successfully.)
> 
> The error message isn't particularly helpful.  We could add another
> error code, such as GNUTLS_E_PREMATURE_CLOSE or similar instead.  What
> do you think?

Adding a new error code for this would be really useful, yes.  An HTTP 
client can safely ignore a premature FIN in cases where it knows the 
application data has been completely transferred (e.g. using the 
Content-Length); being able to distinguish that specific case from other 
failure cases is useful.

In neon at the moment I treat GNUTLS_E_UNEXPECTED_PACKET_LENGTH as 
premature EOF, and even have a note in the code about it being a hack!

joe





From cmaiku at gmail.com  Mon Mar 31 22:48:38 2008
From: cmaiku at gmail.com (Maiku)
Date: Mon, 31 Mar 2008 15:48:38 -0500
Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH
In-Reply-To: <20080331130113.GA31656@manyfish.co.uk>
References: <e39899ed0803310014w45d3813agfe05775cda4568ea@mail.gmail.com>
	<874panyxvx.fsf@mocca.josefsson.org>
	<20080331130113.GA31656@manyfish.co.uk>
Message-ID: <e39899ed0803311348y161ed0el33d2b9461ad29974@mail.gmail.com>

I wanted to clarify a few things I think I missed in my original post. In
the line I posted, when this error happens:

if (ret < 0 && gnutls_error_is_fatal (ret) == 0)

ret is 0. In the _gnutls_io_read_buffered function, it returns on line 639
in gnutls_buffers.c (according to 2.3.4) in this block:

    if (ret == 0)
    {                /* EOF */
      gnutls_assert ();
      return 0;
    }

Also, the gnutls_error_is_fatal returns false (0) for values above zero, and
returns a non-fatal error (0 again) for zero. So to me it appeared that zero
was a case that wasn't being caught properly when checking for less than 0.
My thoughts were that if it was zero it should return as normal (without an
error), the client can then check and see if enough was read, read more if
it needs more, or handle the packet if it's done. This way it doesn't
terminate the session on a return of zero and the client can handle a recv
of zero and the client can handle it however it wishes. It's a sort of case
in itself, I don't believe that would be ignoring it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080331/00e4a519/attachment.htm>