From nmav at gnutls.org  Sun Jun  1 18:14:16 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 01 Jun 2008 19:14:16 +0300
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <20080525080428.GB3208@downhill.g.la>
References: <20080525080428.GB3208@downhill.g.la>
Message-ID: <4842CAD8.106@gnutls.org>

Andreas Metzler wrote:
> Hello,
> 
> gnutls 2.3.11 dpoes not build correctly on sparc.
> 
> http://experimental.debian.net/fetch.php?&pkg=gnutls26&ver=2.3.11-1&arch=sparc&stamp=1211629418&file=log&as=raw
> 
> There is testsuite failure when running openpgpself. (Complete output
> attached). From comparing the output with i386, it looks like i386
> actually does not complete successfully, too - but the error is not
> correctly reflected in the exit code:
> 
> --------------
> client: Handshake failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.
> --------------

Would it be possible to get the output of
certtool --pgp-certificate-info < doc/credentials/openpgp-server.txt
from this platform?

I suspect that the keyid code does not work well there.

regards,
Nikos




From nmav at gnutls.org  Sun Jun  1 18:37:41 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 01 Jun 2008 19:37:41 +0300
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <20080525080428.GB3208@downhill.g.la>
References: <20080525080428.GB3208@downhill.g.la>
Message-ID: <4842D055.2020002@gnutls.org>

Andreas Metzler wrote:
> Hello,
> 
> gnutls 2.3.11 dpoes not build correctly on sparc.
> 
> http://experimental.debian.net/fetch.php?&pkg=gnutls26&ver=2.3.11-1&arch=sparc&stamp=1211629418&file=log&as=raw
> 
> There is testsuite failure when running openpgpself. (Complete output
> attached). From comparing the output with i386, it looks like i386
> actually does not complete successfully, too - but the error is not
> correctly reflected in the exit code:

client |<2>| Importing Openpgp cert and using openpgp sub key:
837b6fb400000402

As it seems the key id reading fails... Only the first 4 bytes are
correct in this system. If possible i'd be interested in the output of
the following program in this system: (I think the output shouldn't be
anything else than 8 but just to eliminate suspicions).

#include <stdio.h>

typedef unsigned char gnutls_openpgp_keyid_t[8];

gnutls_openpgp_keyid_t t;

int main()
{
  printf("size: %u\n", sizeof(t));
}




From ametzler at downhill.at.eu.org  Mon Jun  2 19:18:40 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 2 Jun 2008 19:18:40 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4842CAD8.106@gnutls.org>
References: <20080525080428.GB3208@downhill.g.la> <4842CAD8.106@gnutls.org>
Message-ID: <20080602171840.GA3060@downhill.g.la>

On 2008-06-01 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Andreas Metzler wrote:
> > gnutls 2.3.11 dpoes not build correctly on sparc.
 
> > http://experimental.debian.net/fetch.php?&pkg=gnutls26&ver=2.3.11-1&arch=sparc&stamp=1211629418&file=log&as=raw
 
> > There is testsuite failure when running openpgpself. (Complete output
> > attached). From comparing the output with i386, it looks like i386
> > actually does not complete successfully, too - but the error is not
> > correctly reflected in the exit code:
 
> > --------------
> > client: Handshake failed
> > GNUTLS ERROR: A TLS packet with unexpected length was received.
> > --------------

> Would it be possible to get the output of
> certtool --pgp-certificate-info < doc/credentials/openpgp-server.txt
> from this platform?

> I suspect that the keyid code does not work well there.

The output is identical to the one on i386:

(sid)ametzler at sperger:/tmp/GNUTLS/gnutls26-2.3.11$ src/certtool --pgp-certificate-info < doc/credentials/openpgp-server.txt  2>&1 | md5sum
f12ba2aedb9e221bba4f02e3476b6c76  -

(I can send it, but it seems to be useless.)

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 ametzler at downhill.at.eu.org  Mon Jun  2 19:22:52 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 2 Jun 2008 19:22:52 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4842D055.2020002@gnutls.org>
References: <20080525080428.GB3208@downhill.g.la> <4842D055.2020002@gnutls.org>
Message-ID: <20080602172252.GB3060@downhill.g.la>

On 2008-06-01 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> the following program in this system: (I think the output shouldn't be
> anything else than 8 but just to eliminate suspicions).

> #include <stdio.h>

> typedef unsigned char gnutls_openpgp_keyid_t[8];

> gnutls_openpgp_keyid_t t;

> int main()
> {
>   printf("size: %u\n", sizeof(t));
> }

Hello,

size: 8

cu andreas




From nmav at gnutls.org  Mon Jun  2 22:00:58 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 02 Jun 2008 23:00:58 +0300
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <20080602172252.GB3060@downhill.g.la>
References: <20080525080428.GB3208@downhill.g.la> <4842D055.2020002@gnutls.org>
	<20080602172252.GB3060@downhill.g.la>
Message-ID: <4844517A.3030002@gnutls.org>

Andreas Metzler wrote:
> On 2008-06-01 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> [...]
>> the following program in this system: (I think the output shouldn't be
>> anything else than 8 but just to eliminate suspicions).
> 
>> #include <stdio.h>
> 
>> typedef unsigned char gnutls_openpgp_keyid_t[8];
> 
>> gnutls_openpgp_keyid_t t;
> 
>> int main()
>> {
>>   printf("size: %u\n", sizeof(t));
>> }
> 
> Hello,
> 
> size: 8

This is really strange error. Something that has been set using
gnutls_openpgp_crt_set_preferred_key_id() is returned differently when
gnutls_openpgp_crt_get_preferred_key_id() is used. Maybe the output of
valgrind might help when running openpgpself (in my system it prints
nothing suspicious).

As far as I understand this is a big endian machine but endianess
shouldn't affect the code that is involved. Do you have results of make
check in other big endian systems? If yes and they are successful could
it be a compiler issue?

If the above don't help I'd appreciate if it was possible to have access
in this system to try to debug it with gdb,

regards,
Nikos




From ametzler at downhill.at.eu.org  Tue Jun  3 19:30:05 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 3 Jun 2008 19:30:05 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4844517A.3030002@gnutls.org>
References: <20080525080428.GB3208@downhill.g.la> <4842D055.2020002@gnutls.org>
	<20080602172252.GB3060@downhill.g.la> <4844517A.3030002@gnutls.org>
Message-ID: <20080603173005.GB3575@downhill.g.la>

On 2008-06-02 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> As far as I understand this is a big endian machine but endianess
> shouldn't affect the code that is involved. Do you have results of make
> check in other big endian systems? If yes and they are successful could
> it be a compiler issue?

Hello,

the error was on sperger.debian.org (sparc) According to
http://experimental.debian.net/build.php?pkg=gnutls26 PowerPC built
successfully. - The page features a link to the complete buildlog.

> If the above don't help I'd appreciate if it was possible to have access
> in this system to try to debug it with gdb,

I do not knoww whether it is possible to grant non-debian-developers
access to project machines, but I'll ask.
cu andreas




From simon at josefsson.org  Wed Jun  4 05:21:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 05:21:34 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4844517A.3030002@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 02 Jun 2008 23:00:58 +0300")
References: <20080525080428.GB3208@downhill.g.la>
	<4842D055.2020002@gnutls.org> <20080602172252.GB3060@downhill.g.la>
	<4844517A.3030002@gnutls.org>
Message-ID: <87y75lanr5.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Andreas Metzler wrote:
>> On 2008-06-01 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> [...]
>>> the following program in this system: (I think the output shouldn't be
>>> anything else than 8 but just to eliminate suspicions).
>> 
>>> #include <stdio.h>
>> 
>>> typedef unsigned char gnutls_openpgp_keyid_t[8];
>> 
>>> gnutls_openpgp_keyid_t t;
>> 
>>> int main()
>>> {
>>>   printf("size: %u\n", sizeof(t));
>>> }
>> 
>> Hello,
>> 
>> size: 8
>
> This is really strange error. Something that has been set using
> gnutls_openpgp_crt_set_preferred_key_id() is returned differently when
> gnutls_openpgp_crt_get_preferred_key_id() is used. Maybe the output of
> valgrind might help when running openpgpself (in my system it prints
> nothing suspicious).
>
> As far as I understand this is a big endian machine but endianess
> shouldn't affect the code that is involved. Do you have results of make
> check in other big endian systems? If yes and they are successful could
> it be a compiler issue?
>
> If the above don't help I'd appreciate if it was possible to have access
> in this system to try to debug it with gdb,

FWIW, this seems to happen on my system as well, a normal x86 debian
box.  Does it work on your machine?  There are valgrind errors, see
below.

/Simon

==18506== Memcheck, a memory error detector.
==18506== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==18506== Using LibVEX rev 1804, a library for dynamic binary translation.
==18506== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==18506== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==18506== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==18506== For more details, rerun with: -v
==18506== 
==18506== Use of uninitialised value of size 4
==18506==    at 0x4181141: (within /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x4183079: vfprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x41A0E9B: vsprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x418B24D: sprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x40600D6: _gnutls_bin2hex (gnutls_str.c:265)
==18506==    by 0x406E19E: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:731)
==18506==    by 0x406EA83: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:149)
==18506==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18506==    by 0x8049AAC: server_start (openpgpself.c:391)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== Conditional jump or move depends on uninitialised value(s)
==18506==    at 0x4181147: (within /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x4183079: vfprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x41A0E9B: vsprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x418B24D: sprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x40600D6: _gnutls_bin2hex (gnutls_str.c:265)
==18506==    by 0x406E19E: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:731)
==18506==    by 0x406EA83: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:149)
==18506==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18506==    by 0x8049AAC: server_start (openpgpself.c:391)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== Conditional jump or move depends on uninitialised value(s)
==18506==    at 0x4182D9D: vfprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x41A0E9B: vsprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x418B24D: sprintf (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x40600D6: _gnutls_bin2hex (gnutls_str.c:265)
==18506==    by 0x406E19E: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:731)
==18506==    by 0x406EA83: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:149)
==18506==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18506==    by 0x8049AAC: server_start (openpgpself.c:391)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
client |<2>| Importing Openpgp key and using openpgp sub key: 837b6fb4f0d53104
==18506== 
==18506== Conditional jump or move depends on uninitialised value(s)
==18506==    at 0x409650A: _gnutls_openpgp_find_subkey_idx (pgp.c:753)
==18506==    by 0x4099E49: gnutls_openpgp_privkey_get_subkey_idx (privkey.c:501)
==18506==    by 0x406E1E3: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:736)
==18506==    by 0x406EA83: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:149)
==18506==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18506==    by 0x8049AAC: server_start (openpgpself.c:391)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
client |<2>| ASSERT: pgp.c:762
client |<2>| ASSERT: privkey.c:505
client |<2>| ASSERT: gnutls_openpgp.c:739
client |<2>| ASSERT: gnutls_openpgp.c:152
client |<2>| ASSERT: privkey.c:1058
client |<2>| Importing Openpgp key and using main openpgp key.
client |<2>| ASSERT: pgp.c:1460
client |<2>| Importing Openpgp cert and using main openpgp key
client |<2>| ASSERT: pgp.c:156
client |<2>| EXT[432bef0]: Sending extension CERT_TYPE
client |<2>| ASSERT: gnutls_cipher.c:205
server |<2>| ASSERT: gnutls_cipher.c:205
server |<2>| ASSERT: gnutls_db.c:238
server |<2>| EXT[431dde8]: Received extension 'CERT_TYPE/9'
server |<2>| EXT[431dde8]: Received extension 'CERT_TYPE/9'
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: ext_cert_type.c:123
server |<2>| ASSERT: gnutls_handshake.c:2875
server |<1>| Could not find an appropriate certificate: Insufficient credentials for that request.
server |<2>| ASSERT: gnutls_handshake.c:706
server |<2>| ASSERT: gnutls_handshake.c:465
server |<2>| ASSERT: gnutls_handshake.c:2024
server |<2>| ASSERT: gnutls_handshake.c:2550
client |<2>| ASSERT: gnutls_buffers.c:638
client |<2>| ASSERT: gnutls_record.c:909
client |<2>| ASSERT: gnutls_buffers.c:1152
client |<2>| ASSERT: gnutls_handshake.c:1031
client |<2>| ASSERT: gnutls_handshake.c:2330
server: Handshake has failed (Could not negotiate a supported cipher suite.)

client: Handshake failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
Setting key files...
Connecting...
==18507== 
==18507== ERROR SUMMARY: 15 errors from 4 contexts (suppressed: 21 from 1)
==18507== malloc/free: in use at exit: 69,062 bytes in 4,046 blocks.
==18507== malloc/free: 5,824 allocs, 1,778 frees, 188,294 bytes allocated.
==18507== For counts of detected errors, rerun with: -v
==18507== searching for pointers to 4,046 not-freed blocks.
==18507== checked 174,588 bytes.
==18507== 
==18507== 
==18507== 4 bytes in 1 blocks are still reachable in loss record 1 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x4125497: _gcry_mpi_alloc_limb_space (mpiutil.c:92)
==18507==    by 0x4125570: _gcry_mpi_alloc (mpiutil.c:54)
==18507==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18507==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18507==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18507==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18507==    by 0x405F3D3: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:379)
==18507==    by 0x8049B06: server_start (openpgpself.c:289)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 8 bytes in 1 blocks are still reachable in loss record 2 of 22
==18507==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18507==    by 0x405EA88: gnutls_dh_params_init (gnutls_dh_primes.c:195)
==18507==    by 0x8049AEA: server_start (openpgpself.c:288)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 20 bytes in 1 blocks are still reachable in loss record 3 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x4125558: _gcry_mpi_alloc (mpiutil.c:53)
==18507==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18507==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18507==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18507==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18507==    by 0x405F3D3: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:379)
==18507==    by 0x8049B06: server_start (openpgpself.c:289)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 20 bytes in 1 blocks are still reachable in loss record 4 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x4125558: _gcry_mpi_alloc (mpiutil.c:53)
==18507==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18507==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18507==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18507==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18507==    by 0x405F3AA: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:369)
==18507==    by 0x8049B06: server_start (openpgpself.c:289)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 32 bytes in 1 blocks are still reachable in loss record 5 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x4022BFC: realloc (vg_replace_malloc.c:429)
==18507==    by 0x4059E2E: gnutls_realloc_fast (gnutls_mem.c:79)
==18507==    by 0x406EA5E: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:140)
==18507==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18507==    by 0x8049AAC: server_start (openpgpself.c:391)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 76 bytes in 1 blocks are still reachable in loss record 6 of 22
==18507==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18507==    by 0x4056968: gnutls_certificate_allocate_credentials (gnutls_cert.c:275)
==18507==    by 0x8049A7F: server_start (openpgpself.c:389)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 98 bytes in 9 blocks are still reachable in loss record 7 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18507==    by 0x429B638: asn1_array2tree (structure.c:205)
==18507==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 120 bytes in 5 blocks are still reachable in loss record 8 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18507==    by 0x40DE65B: do_malloc (global.c:560)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18507==    by 0x40E58E3: gcry_pk_register_default (pubkey.c:194)
==18507==    by 0x40E5BC3: _gcry_pk_init (pubkey.c:2578)
==18507==    by 0x40DEB6D: global_init (global.c:89)
==18507==    by 0x40DF191: _gcry_check_version (global.c:171)
==18507==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18507==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 128 bytes in 1 blocks are still reachable in loss record 9 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x4125497: _gcry_mpi_alloc_limb_space (mpiutil.c:92)
==18507==    by 0x4125570: _gcry_mpi_alloc (mpiutil.c:54)
==18507==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18507==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18507==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18507==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18507==    by 0x405F3AA: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:369)
==18507==    by 0x8049B06: server_start (openpgpself.c:289)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 129 bytes in 59 blocks are still reachable in loss record 10 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18507==    by 0x42995AB: _asn1_change_integer_value (parser_aux.c:534)
==18507==    by 0x429B7EF: asn1_array2tree (structure.c:249)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 312 bytes in 13 blocks are still reachable in loss record 11 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18507==    by 0x40DE65B: do_malloc (global.c:560)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18507==    by 0x40EDA3F: gcry_md_register_default (md.c:154)
==18507==    by 0x40EDAB3: _gcry_md_init (md.c:1252)
==18507==    by 0x40DEB64: global_init (global.c:86)
==18507==    by 0x40DF191: _gcry_check_version (global.c:171)
==18507==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18507==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 432 bytes in 18 blocks are still reachable in loss record 12 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18507==    by 0x40DE65B: do_malloc (global.c:560)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18507==    by 0x40E3471: gcry_cipher_register_default (cipher.c:272)
==18507==    by 0x40E3533: _gcry_cipher_init (cipher.c:1711)
==18507==    by 0x40DEB34: global_init (global.c:83)
==18507==    by 0x40DF191: _gcry_check_version (global.c:171)
==18507==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18507==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 502 bytes in 52 blocks are still reachable in loss record 13 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18507==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18507==    by 0x429B614: asn1_array2tree (structure.c:203)
==18507==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 664 bytes in 1 blocks are still reachable in loss record 14 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x40DE90C: _gcry_xcalloc (global.c:770)
==18507==    by 0x40F152B: initialize (random.c:337)
==18507==    by 0x40F215E: _gcry_randomize (random.c:563)
==18507==    by 0x40DBC9A: gcry_randomize (visibility.c:1056)
==18507==    by 0x406FE0B: gc_pseudo_random (gc-libgcrypt.c:83)
==18507==    by 0x4067C62: _gnutls_rnd_init (random.c:51)
==18507==    by 0x4057C4F: gnutls_global_init (gnutls_global.c:309)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 664 bytes in 1 blocks are still reachable in loss record 15 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x40DE626: do_malloc (global.c:558)
==18507==    by 0x40DE859: _gcry_malloc (global.c:582)
==18507==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18507==    by 0x40DE90C: _gcry_xcalloc (global.c:770)
==18507==    by 0x40F146B: initialize (random.c:334)
==18507==    by 0x40F215E: _gcry_randomize (random.c:563)
==18507==    by 0x40DBC9A: gcry_randomize (visibility.c:1056)
==18507==    by 0x406FE0B: gc_pseudo_random (gc-libgcrypt.c:83)
==18507==    by 0x4067C62: _gnutls_rnd_init (random.c:51)
==18507==    by 0x4057C4F: gnutls_global_init (gnutls_global.c:309)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 1,188 bytes in 492 blocks are still reachable in loss record 16 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18507==    by 0x4299FAE: _asn1_expand_object_id (parser_aux.c:627)
==18507==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 1,512 bytes in 54 blocks are still reachable in loss record 17 of 22
==18507==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18507==    by 0x429A05C: _asn1_add_node (parser_aux.c:62)
==18507==    by 0x429B5FB: asn1_array2tree (structure.c:201)
==18507==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 3,431 bytes in 401 blocks are still reachable in loss record 18 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18507==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18507==    by 0x4299F7A: _asn1_expand_object_id (parser_aux.c:624)
==18507==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 5,338 bytes in 655 blocks are still reachable in loss record 19 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18507==    by 0x429B638: asn1_array2tree (structure.c:205)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 12,020 bytes in 766 blocks are still reachable in loss record 20 of 22
==18507==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18507==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18507==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18507==    by 0x429B614: asn1_array2tree (structure.c:203)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 13,776 bytes in 492 blocks are still reachable in loss record 21 of 22
==18507==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18507==    by 0x429BA85: _asn1_add_node_only (structure.c:54)
==18507==    by 0x4299F60: _asn1_expand_object_id (parser_aux.c:623)
==18507==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== 
==18507== 28,588 bytes in 1,021 blocks are still reachable in loss record 22 of 22
==18507==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18507==    by 0x429A05C: _asn1_add_node (parser_aux.c:62)
==18507==    by 0x429B5FB: asn1_array2tree (structure.c:201)
==18507==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18507==    by 0x8049A5B: server_start (openpgpself.c:384)
==18507==    by 0x804A6BA: doit (openpgpself.c:514)
==18507==    by 0x804A814: main (utils.c:148)
==18507== 
==18507== LEAK SUMMARY:
==18507==    definitely lost: 0 bytes in 0 blocks.
==18507==      possibly lost: 0 bytes in 0 blocks.
==18507==    still reachable: 69,062 bytes in 4,046 blocks.
==18507==         suppressed: 0 bytes in 0 blocks.
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
server: connection from 127.0.0.1, port 39261
==18506== 
==18506== ERROR SUMMARY: 15 errors from 4 contexts (suppressed: 21 from 1)
==18506== malloc/free: in use at exit: 69,062 bytes in 4,046 blocks.
==18506== malloc/free: 5,661 allocs, 1,615 frees, 152,551 bytes allocated.
==18506== For counts of detected errors, rerun with: -v
==18506== searching for pointers to 4,046 not-freed blocks.
==18506== checked 174,592 bytes.
==18506== 
==18506== 
==18506== 4 bytes in 1 blocks are still reachable in loss record 1 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x4125497: _gcry_mpi_alloc_limb_space (mpiutil.c:92)
==18506==    by 0x4125570: _gcry_mpi_alloc (mpiutil.c:54)
==18506==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18506==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18506==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18506==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18506==    by 0x405F3D3: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:379)
==18506==    by 0x8049B06: server_start (openpgpself.c:289)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 8 bytes in 1 blocks are still reachable in loss record 2 of 22
==18506==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18506==    by 0x405EA88: gnutls_dh_params_init (gnutls_dh_primes.c:195)
==18506==    by 0x8049AEA: server_start (openpgpself.c:288)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 20 bytes in 1 blocks are still reachable in loss record 3 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x4125558: _gcry_mpi_alloc (mpiutil.c:53)
==18506==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18506==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18506==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18506==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18506==    by 0x405F3D3: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:379)
==18506==    by 0x8049B06: server_start (openpgpself.c:289)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 20 bytes in 1 blocks are still reachable in loss record 4 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x4125558: _gcry_mpi_alloc (mpiutil.c:53)
==18506==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18506==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18506==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18506==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18506==    by 0x405F3AA: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:369)
==18506==    by 0x8049B06: server_start (openpgpself.c:289)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 32 bytes in 1 blocks are still reachable in loss record 5 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x4022BFC: realloc (vg_replace_malloc.c:429)
==18506==    by 0x4059E2E: gnutls_realloc_fast (gnutls_mem.c:79)
==18506==    by 0x406EA5E: gnutls_certificate_set_openpgp_key (gnutls_openpgp.c:140)
==18506==    by 0x406EE6E: gnutls_certificate_set_openpgp_key_mem2 (gnutls_openpgp.c:424)
==18506==    by 0x8049AAC: server_start (openpgpself.c:391)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 76 bytes in 1 blocks are still reachable in loss record 6 of 22
==18506==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18506==    by 0x4056968: gnutls_certificate_allocate_credentials (gnutls_cert.c:275)
==18506==    by 0x8049A7F: server_start (openpgpself.c:389)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 98 bytes in 9 blocks are still reachable in loss record 7 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18506==    by 0x429B638: asn1_array2tree (structure.c:205)
==18506==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 120 bytes in 5 blocks are still reachable in loss record 8 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18506==    by 0x40DE65B: do_malloc (global.c:560)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18506==    by 0x40E58E3: gcry_pk_register_default (pubkey.c:194)
==18506==    by 0x40E5BC3: _gcry_pk_init (pubkey.c:2578)
==18506==    by 0x40DEB6D: global_init (global.c:89)
==18506==    by 0x40DF191: _gcry_check_version (global.c:171)
==18506==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18506==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 128 bytes in 1 blocks are still reachable in loss record 9 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x4125497: _gcry_mpi_alloc_limb_space (mpiutil.c:92)
==18506==    by 0x4125570: _gcry_mpi_alloc (mpiutil.c:54)
==18506==    by 0x4123559: _gcry_mpi_scan (mpicoder.c:379)
==18506==    by 0x40DD598: gcry_mpi_scan (visibility.c:297)
==18506==    by 0x4054A48: _gnutls_mpi_scan (gnutls_mpi.c:53)
==18506==    by 0x4054B95: _gnutls_x509_read_int (gnutls_mpi.c:228)
==18506==    by 0x405F3AA: gnutls_dh_params_import_pkcs3 (gnutls_dh_primes.c:369)
==18506==    by 0x8049B06: server_start (openpgpself.c:289)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 129 bytes in 59 blocks are still reachable in loss record 10 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18506==    by 0x42995AB: _asn1_change_integer_value (parser_aux.c:534)
==18506==    by 0x429B7EF: asn1_array2tree (structure.c:249)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 312 bytes in 13 blocks are still reachable in loss record 11 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18506==    by 0x40DE65B: do_malloc (global.c:560)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18506==    by 0x40EDA3F: gcry_md_register_default (md.c:154)
==18506==    by 0x40EDAB3: _gcry_md_init (md.c:1252)
==18506==    by 0x40DEB64: global_init (global.c:86)
==18506==    by 0x40DF191: _gcry_check_version (global.c:171)
==18506==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18506==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 432 bytes in 18 blocks are still reachable in loss record 12 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40E1E0F: _gcry_private_malloc (stdmem.c:106)
==18506==    by 0x40DE65B: do_malloc (global.c:560)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40E2A86: _gcry_module_add (module.c:89)
==18506==    by 0x40E3471: gcry_cipher_register_default (cipher.c:272)
==18506==    by 0x40E3533: _gcry_cipher_init (cipher.c:1711)
==18506==    by 0x40DEB34: global_init (global.c:83)
==18506==    by 0x40DF191: _gcry_check_version (global.c:171)
==18506==    by 0x40DDC9C: gcry_check_version (visibility.c:66)
==18506==    by 0x4057A55: gnutls_global_init (gnutls_global.c:243)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 502 bytes in 52 blocks are still reachable in loss record 13 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18506==    by 0x429B614: asn1_array2tree (structure.c:203)
==18506==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 664 bytes in 1 blocks are still reachable in loss record 14 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x40DE90C: _gcry_xcalloc (global.c:770)
==18506==    by 0x40F152B: initialize (random.c:337)
==18506==    by 0x40F215E: _gcry_randomize (random.c:563)
==18506==    by 0x40DBC9A: gcry_randomize (visibility.c:1056)
==18506==    by 0x406FE0B: gc_pseudo_random (gc-libgcrypt.c:83)
==18506==    by 0x4067C62: _gnutls_rnd_init (random.c:51)
==18506==    by 0x4057C4F: gnutls_global_init (gnutls_global.c:309)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 664 bytes in 1 blocks are still reachable in loss record 15 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x40DE626: do_malloc (global.c:558)
==18506==    by 0x40DE859: _gcry_malloc (global.c:582)
==18506==    by 0x40DE87D: _gcry_xmalloc (global.c:717)
==18506==    by 0x40DE90C: _gcry_xcalloc (global.c:770)
==18506==    by 0x40F146B: initialize (random.c:334)
==18506==    by 0x40F215E: _gcry_randomize (random.c:563)
==18506==    by 0x40DBC9A: gcry_randomize (visibility.c:1056)
==18506==    by 0x406FE0B: gc_pseudo_random (gc-libgcrypt.c:83)
==18506==    by 0x4067C62: _gnutls_rnd_init (random.c:51)
==18506==    by 0x4057C4F: gnutls_global_init (gnutls_global.c:309)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 1,188 bytes in 492 blocks are still reachable in loss record 16 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18506==    by 0x4299FAE: _asn1_expand_object_id (parser_aux.c:627)
==18506==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 1,512 bytes in 54 blocks are still reachable in loss record 17 of 22
==18506==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18506==    by 0x429A05C: _asn1_add_node (parser_aux.c:62)
==18506==    by 0x429B5FB: asn1_array2tree (structure.c:201)
==18506==    by 0x4057C2D: gnutls_global_init (gnutls_global.c:300)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 3,431 bytes in 401 blocks are still reachable in loss record 18 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18506==    by 0x4299F7A: _asn1_expand_object_id (parser_aux.c:624)
==18506==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 5,338 bytes in 655 blocks are still reachable in loss record 19 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x42994BB: _asn1_set_value (parser_aux.c:216)
==18506==    by 0x429B638: asn1_array2tree (structure.c:205)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 12,020 bytes in 766 blocks are still reachable in loss record 20 of 22
==18506==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==18506==    by 0x41B5E3F: strdup (in /lib/i686/cmov/libc-2.7.so)
==18506==    by 0x429944D: _asn1_set_name (parser_aux.c:252)
==18506==    by 0x429B614: asn1_array2tree (structure.c:203)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 13,776 bytes in 492 blocks are still reachable in loss record 21 of 22
==18506==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18506==    by 0x429BA85: _asn1_add_node_only (structure.c:54)
==18506==    by 0x4299F60: _asn1_expand_object_id (parser_aux.c:623)
==18506==    by 0x429B7FC: asn1_array2tree (structure.c:250)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== 
==18506== 28,588 bytes in 1,021 blocks are still reachable in loss record 22 of 22
==18506==    at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==18506==    by 0x429A05C: _asn1_add_node (parser_aux.c:62)
==18506==    by 0x429B5FB: asn1_array2tree (structure.c:201)
==18506==    by 0x4057BFA: gnutls_global_init (gnutls_global.c:293)
==18506==    by 0x8049A5B: server_start (openpgpself.c:384)
==18506==    by 0x804A6BA: doit (openpgpself.c:514)
==18506==    by 0x804A814: main (utils.c:148)
==18506== 
==18506== LEAK SUMMARY:
==18506==    definitely lost: 0 bytes in 0 blocks.
==18506==      possibly lost: 0 bytes in 0 blocks.
==18506==    still reachable: 69,062 bytes in 4,046 blocks.
==18506==         suppressed: 0 bytes in 0 blocks.




From simon at josefsson.org  Wed Jun  4 08:16:25 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 08:16:25 +0200
Subject: GnuTLS 2.3.4.netconf.2
Message-ID: <87fxrtafnq.fsf@mocca.josefsson.org>

There is a branch 'gnutls_with_netconf' for the goal of implementing
support for Netconf over TLS-PSK as per this IETF draft:
<http://tools.ietf.org/html/draft-ietf-netconf-tls>.

This is the third release from this branch, and it adds support for
sending the psk_identity_hint in the server and enhanced documentation
on how to use the new features.

The branch is currently based on gnutls 2.3.4, which explains the
version numbers in the tar archive filename.

The goal is to merge this with the development branch eventually.

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

Happy hacking,
Simon

* Version 2.3.4.netconf.2 (released 2008-06-04)

** libgnutls [PSK]: New API to retrieve PSK identity hint in client.
The function is gnutls_psk_client_get_hint.

** libgnutls [PSK]: New API to set PSK identity hint in server.
The function is gnutls_psk_set_server_credentials_hint.

** libgnutls [PSK]: Will send server key exchange with PSK identity hint.
The message is sent if the application has specified a PSK identity
hint using gnutls_psk_set_server_credentials_hint.

** psktool: Support new --netconf-hint to generate PSK key from password.
Uses the Netconf algorithm to derive PSK key from password.

** gnutls-serv: Support new --pskhint parameter to set PSK identity hint.

** gnutls-cli: Always support PSK modes, through a callback.
The callback will derive a PSK key using Netconf algorithm.  It will
print the PSK identity hint to help the user.

** API and ABI modifications:
gnutls_psk_client_get_hint: ADDED.
gnutls_psk_set_server_credentials_hint: ADDED.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080604/cf354ee3/attachment.pgp>

From simon at josefsson.org  Wed Jun  4 11:44:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 11:44:58 +0200
Subject: GnuTLS 2.3.12 - first release candidate for 2.4.0
Message-ID: <87zlq17cv9.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.

This release merges the gnutls_with_netconf branch, and is likely the
last feature-related work on the 2.3.x branch.  This the first release
candidate for 2.4.0.  Anything that doesn't live up to the expectations
on a stable release should be reported before this turns into the real
2.4.0.  I'll post updated draft 2.4.0 release notes separately.

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

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

Alas, the spammers have found our trac site so it is almost useless. :(
Hopefully I can move it to another host soon...  Is anyone interested in
helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!

More ideas are welcome, just create a new ticket.

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

Here is the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.3.12.exe
  http://josefsson.org/gnutls4win/gnutls-2.3.12.zip

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.12-1_all.deb

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.

News in this release:

* Version 2.3.12 (released 2008-06-04)

** Merge gnutls_with_netconf branch.

*** libgnutls [PSK]: New API to retrieve PSK identity hint in client.
The function is gnutls_psk_client_get_hint.

*** libgnutls [PSK]: New API to set PSK identity hint in server.
The function is gnutls_psk_set_server_credentials_hint.

*** libgnutls [PSK]: Support server key exchange with PSK identity hint.
In the client, the message is parsed and the application can use
gnutls_psk_client_get_hint to retrieve the hint.  In the server, the
message is sent if the application has specified a PSK identity hint
using gnutls_psk_set_server_credentials_hint.

*** libgnutls [PSK]: Support Netconf PSK key derivation.
The function gnutls_psk_netconf_derive_key supports the PSK key
derivation as specified in draft-ietf-netconf-tls-02.txt.  New self
test netconf-psk.c.

*** psktool: Support new --netconf-hint to generate PSK key from password.
Uses the Netconf algorithm to derive PSK key from password.

*** gnutls-serv: Support new --pskhint parameter to set PSK identity hint.

*** gnutls-cli: Always support PSK modes, through a callback.
The callback will derive a PSK key using Netconf algorithm.  It will
print the PSK identity hint to help the user.

*** New PSK example client and server.
See doc/examples/ex-client-psk.c and doc/examples/ex-serv-psk.c.

** libgnutls: Fix gnutls_x509_crl_set_version on arm platforms.
The code didn't work properly on platforms where 'char' is unsigned,
when you set version 0.  Reported by Laurence Withers
<l at lwithers.me.uk> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2825>.

** libgnutls-openssl: added RAND_pseudo_bytes API.
Patch from Robert Millan <rmh at aybabtu.com>.

** API and ABI modifications:
RAND_pseudo_bytes: ADDED to libgnutls-openssl.
gnutls_psk_client_get_hint: ADDED.
gnutls_psk_set_server_credentials_hint: ADDED.
gnutls_psk_netconf_derive_key: ADDED

/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/20080604/5204d1ec/attachment.pgp>

From simon at josefsson.org  Wed Jun  4 11:51:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 11:51:04 +0200
Subject: Draft of GnuTLS 2.4.0 release notes
In-Reply-To: <87prr9qcy1.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 26 May 2008 17:53:26 +0200")
References: <87prr9qcy1.fsf@mocca.josefsson.org>
Message-ID: <87tzg97cl3.fsf@mocca.josefsson.org>

Updated release notes below.

The notes says that we have bumped the ABI version, but this isn't done
in the 2.3.12 release yet.  I'm still not fully decided here, but I'm
leaning towards bumping the ABI.

/Simon

What's New
==========

Major end-user visible changes compared to the v2.2 branch:

* The PSK sub-system has been improved and now supports password
  derivation and PSK identity hints.

  The password derivation algorithms support is documented in
  draft-ietf-netconf-tls-02.txt.

* The certtool --inder and --outder has been replaced by --inraw and --outraw.

  This aligns terminology with OpenPGP, which doesn't use DER
  encoding.  The old parameters will continue to work for some time.

* Certtool now confirm passwords and changes permissions of private key files.

* The default handshake size limit has been increased to 48kb.

  It appears as if some valid handshakes are large due to sending many
  CA certificates.  (The earlier limit was 16kb.)

* LZO compression is now disabled by default.

  The main reason is that LZO compression in TLS is not standardized,
  but license compatiblity issues with minilzo triggered us to make
  this decision now.

* Improvements for cross-compilation to Windows and OpenWRT.

* The look of the GTK-DOC manual has been improved.

Major developer visible changes compared to the v2.2 branch:

* Full OpenPGP support is part of libgnutls, licensed under the LGPL.

* New APIs to access the raw X.509 Subject and Issuer DN's and
  elements from the certificate credentials structure, thanks to Joe
  Orton.

* New APIs to improve working with username/passwords and PSK.

* Names of constants to affect certificate printing changed.

  The constants are used for OpenPGP too, which the names didn't
  reflect, so the following change has been made:

            Old name                         New name
     GNUTLS_X509_CRT_FULL            GNUTLS_CRT_PRINT_FULL
     GNUTLS_X509_CRT_ONELINE         GNUTLS_CRT_PRINT_ONELINE
     GNUTLS_X509_CRT_UNSIGNED_FULL   GNUTLS_CRT_PRINT_UNSIGNED_FULL

  The old names will be mapped to the new names for some time.

* The function gnutls_openpgp_privkey_get_id has been renamed to
  gnutls_openpgp_privkey_get_key_id.

* Replaced all uses of alloca with malloc and free.

* We no longer build with -D_REENTRANT -D_THREAD_SAFE.

  We have been unable to find a documented rationale for this
  practice.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.4
=============================

All OpenPGP functions have been moved from libgnutls-extra to
libgnutls, and several new functions have been added to support
OpenPGP subkeys (see below).  Even though all programs that link to
libgnutls-extra for the OpenPGP symbols also links to libgnutls, we
felt that strictly speaking we have removed some symbols from the
libgnutls-extra library.  Removing a function from a shared library
requires you to increment the shared library version.  We are thus
increasing the shared library version of GnuTLS.  You need to
recompile all your programs linked with GnuTLS to make them work with
this GnuTLS release.

(We considered to bump the shared library version only for
libgnutls-extra, since again strictly speaking we have not removed any
functions from libgnutls, but that may lead to problems when a
libgnutls-extra from 2.2.x pulls in libgnutls from 2.4.x.  By
incrementing the version of both libraries, it is guaranteed that they
will only be linked with each other.)

This release adds a small set of new API functions:

  gnutls_psk_client_get_hint
  gnutls_psk_set_server_credentials_hint
  gnutls_psk_netconf_derive_key

    Used to get/set the PSK identity hint, and derive PSK keys from
    passwords.

  gnutls_x509_dn_deinit
  gnutls_x509_dn_export
  gnutls_x509_dn_import
  gnutls_x509_dn_init

    Used to handle X.509 Certificate DN's directly.

  gnutls_hex2bin

    Converts a data buffer to hex.  Useful for handling PSK/SRP shared
    secrets.

  gnutls_certificate_get_x509_cas
  gnutls_certificate_get_x509_crls
  gnutls_certificate_get_openpgp_keyring

    Direct access to credential elements.

  gnutls_openpgp_crt_get_auth_subkey
  gnutls_openpgp_crt_get_key_id
  gnutls_openpgp_crt_get_pk_dsa_raw
  gnutls_openpgp_crt_get_pk_rsa_raw
  gnutls_openpgp_crt_get_preferred_key_id
  gnutls_openpgp_crt_get_revoked_status
  gnutls_openpgp_crt_get_subkey_count
  gnutls_openpgp_crt_get_subkey_creation_time
  gnutls_openpgp_crt_get_subkey_expiration_time
  gnutls_openpgp_crt_get_subkey_id
  gnutls_openpgp_crt_get_subkey_idx
  gnutls_openpgp_crt_get_subkey_pk_algorithm
  gnutls_openpgp_crt_get_subkey_pk_dsa_raw
  gnutls_openpgp_crt_get_subkey_pk_rsa_raw
  gnutls_openpgp_crt_get_subkey_revoked_status
  gnutls_openpgp_crt_get_subkey_usage
  gnutls_openpgp_crt_print
  gnutls_openpgp_crt_set_preferred_key_id
  gnutls_openpgp_keyring_get_crt
  gnutls_openpgp_keyring_get_crt_count
  gnutls_openpgp_privkey_export
  gnutls_openpgp_privkey_export_dsa_raw
  gnutls_openpgp_privkey_export_rsa_raw
  gnutls_openpgp_privkey_export_subkey_dsa_raw
  gnutls_openpgp_privkey_export_subkey_rsa_raw
  gnutls_openpgp_privkey_get_fingerprint
  gnutls_openpgp_privkey_get_key_id
  gnutls_openpgp_privkey_get_pk_algorithm
  gnutls_openpgp_privkey_get_preferred_key_id
  gnutls_openpgp_privkey_get_revoked_status
  gnutls_openpgp_privkey_get_subkey_count
  gnutls_openpgp_privkey_get_subkey_creation_time
  gnutls_openpgp_privkey_get_subkey_expiration_time
  gnutls_openpgp_privkey_get_subkey_id
  gnutls_openpgp_privkey_get_subkey_idx
  gnutls_openpgp_privkey_get_subkey_pk_algorithm
  gnutls_openpgp_privkey_get_subkey_revoked_status
  gnutls_openpgp_privkey_set_preferred_key_id

    New OpenPGP related functions.

    The function gnutls_openpgp_crt_get_key_id is the same as the old
    from gnutls_openpgp_crt_get_id, see above.

The release also adds a new header file 'gnutls/crypto.h', however it
is currently not used.  During the next development branch, it will be
used to provide functions for applications to replace parts of the
default libgcrypt low-level crypto implementation.  (For example,
applications could provide its own random-number generator.)




From joe at manyfish.co.uk  Wed Jun  4 12:42:54 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 4 Jun 2008 11:42:54 +0100
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <87ej7prvb0.fsf@mocca.josefsson.org>
References: <87ej7prvb0.fsf@mocca.josefsson.org>
Message-ID: <20080604104254.GA20298@manyfish.co.uk>

On Mon, May 26, 2008 at 04:31:31PM +0200, Simon Josefsson wrote:
> 3) Don't increment the shared library version at all.
> 
>    The justification would be that we haven't removed any symbols, all
>    symbols in libgnutls-extra are still available via libgnutls and work
>    the same way.  The only thing that would break here is if someone is
>    dlopen'ing libgnutls-extra.so and calls the openpgp related
>    functions.  Strictly speaking I'm not sure this is a valid approach,
>    since we HAVE removed symbols from libgnutls-extra.

Having looked into this, I can't see why that would break.  dlsym() will 
still find the symbols since libgnutls-extra.so is linked against 
libgnutls; the wording in POSIX is very specific that this must be the 
case.  Attached a test case which finds gnutls_malloc via dlopen of 
libgnutls-extra.so for PoC.

So I think it's very reasonable to argue that the ABI of libgnutls-extra 
has not changed in this case and no soname bump is necessary.

joe






From joe at manyfish.co.uk  Wed Jun  4 12:44:01 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 4 Jun 2008 11:44:01 +0100
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <20080604104254.GA20298@manyfish.co.uk>
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080604104254.GA20298@manyfish.co.uk>
Message-ID: <20080604104401.GB20298@manyfish.co.uk>

On Wed, Jun 04, 2008 at 11:42:54AM +0100, Joe Orton wrote:
> On Mon, May 26, 2008 at 04:31:31PM +0200, Simon Josefsson wrote:
> > 3) Don't increment the shared library version at all.
> > 
> >    The justification would be that we haven't removed any symbols, all
> >    symbols in libgnutls-extra are still available via libgnutls and work
> >    the same way.  The only thing that would break here is if someone is
> >    dlopen'ing libgnutls-extra.so and calls the openpgp related
> >    functions.  Strictly speaking I'm not sure this is a valid approach,
> >    since we HAVE removed symbols from libgnutls-extra.
> 
> Having looked into this, I can't see why that would break.  dlsym() will 
> still find the symbols since libgnutls-extra.so is linked against 
> libgnutls; the wording in POSIX is very specific that this must be the 
> case.  Attached a test case which finds gnutls_malloc via dlopen of 
> libgnutls-extra.so for PoC.

Now, really attached :)

joe

-------------- next part --------------
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    void *handle, *fn;

    handle = dlopen("libgnutls-extra.so", RTLD_NOW|RTLD_LOCAL);
    if (!handle)
        abort();

    fn = dlsym(handle, "gnutls_malloc");
    if (!handle) 
        abort();
    
    puts("ok");
    
    return 0;
}

From tml at iki.fi  Wed Jun  4 15:04:03 2008
From: tml at iki.fi (Tor Lillqvist)
Date: Wed, 4 Jun 2008 16:04:03 +0300
Subject: Suggested fix on Windows: handle also WSAETIMEDOUT after recv()
	returns failure
Message-ID: <c9b6d9a50806040604n7d309ba0v999db8d395fbbbe3@mail.gmail.com>

I have been debugging an interesting problem in Evolution's use of
GnuTLS on Windows. The root cause for the problem was elsewhere, see
below if you are interested. From GnuTLS's point of view the
interesting effect was that the recv() call in _gnutls_read() in
gnutls_buffers.c returned -1, with WSAGetLastError() returning
WSAETIMEDOUT. I think WSAETIMEDOUT should be handled like
WSAEWOULDBLOCK here? At least in this case, doing that made the code
work also without fixing the root cause.

FYI: The root cause for the problem was that libsoup uses setsockopt's
SO_RCVTIMEO and SO_SNDTIMEO options to set the socket's timeout,
passing a pointer to a struct timeval, like on Unix. But... the
Winsock designers, for some reason, decided to change the semantics of
these options: In Winsock the option value is an int, the timeout in
milliseconds. So when libsoup tried to set the timeout to 30 seconds,
it actually set it to 30 milliseconds, eek.) What on Earth were they
thinking when they changed the type of the option value for
SO_RCVTIMEO and SO_SNDTIMEO like this? They should at least have used
a different names for the options when they change the type of their
values. The type unsafety of setsockopt() means the compiler can't
warn either.

There must be something in the water in Redmond, one thinks.

--tml




From simon at josefsson.org  Wed Jun  4 15:54:21 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 15:54:21 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <20080604104254.GA20298@manyfish.co.uk> (Joe Orton's message of
	"Wed, 4 Jun 2008 11:42:54 +0100")
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080604104254.GA20298@manyfish.co.uk>
Message-ID: <87ej7d5mr6.fsf@mocca.josefsson.org>

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

> On Mon, May 26, 2008 at 04:31:31PM +0200, Simon Josefsson wrote:
>> 3) Don't increment the shared library version at all.
>> 
>>    The justification would be that we haven't removed any symbols, all
>>    symbols in libgnutls-extra are still available via libgnutls and work
>>    the same way.  The only thing that would break here is if someone is
>>    dlopen'ing libgnutls-extra.so and calls the openpgp related
>>    functions.  Strictly speaking I'm not sure this is a valid approach,
>>    since we HAVE removed symbols from libgnutls-extra.
>
> Having looked into this, I can't see why that would break.  dlsym() will 
> still find the symbols since libgnutls-extra.so is linked against 
> libgnutls; the wording in POSIX is very specific that this must be the 
> case.  Attached a test case which finds gnutls_malloc via dlopen of 
> libgnutls-extra.so for PoC.
>
> So I think it's very reasonable to argue that the ABI of libgnutls-extra 
> has not changed in this case and no soname bump is necessary.

But what about non-ELF or even systems without shared libraries?

Possibly we could decide that systems that doesn't behave like Linux
here are of too little concern to us, and that they will need to remove
the old libgnutls* when they install gnutls 2.4.x.  It would be good to
know if there is any significant system that will be affected before
deciding this though.  I'll try to build gnutls 2.2 and 2.3 on solaris
and see if I can run an openpgp application linked to 2.2 with the 2.4
libraries.

Maybe we should ask on the Libtool list, or some shared library guru
like Uli...

/Simon




From simon at josefsson.org  Wed Jun  4 16:06:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Jun 2008 16:06:13 +0200
Subject: Suggested fix on Windows: handle also WSAETIMEDOUT after recv()
	returns failure
In-Reply-To: <c9b6d9a50806040604n7d309ba0v999db8d395fbbbe3@mail.gmail.com>
	(Tor Lillqvist's message of "Wed, 4 Jun 2008 16:04:03 +0300")
References: <c9b6d9a50806040604n7d309ba0v999db8d395fbbbe3@mail.gmail.com>
Message-ID: <87abi15m7e.fsf@mocca.josefsson.org>

"Tor Lillqvist" <tml at iki.fi> writes:

> I have been debugging an interesting problem in Evolution's use of
> GnuTLS on Windows. The root cause for the problem was elsewhere, see
> below if you are interested. From GnuTLS's point of view the
> interesting effect was that the recv() call in _gnutls_read() in
> gnutls_buffers.c returned -1, with WSAGetLastError() returning
> WSAETIMEDOUT. I think WSAETIMEDOUT should be handled like
> WSAEWOULDBLOCK here? At least in this case, doing that made the code
> work also without fixing the root cause.

According to MSDN, WSAETIMEDOUT means the connection has been "dropped":

http://msdn.microsoft.com/en-us/library/ms740121(VS.85).aspx

  "The connection has been dropped because of a network failure or
  because the peer system failed to respond."

Are you saying that calling recv again after a WSAETIMEDOUT actually
results in data sooner or later?  If so, I suggest we install this:

diff --git a/lib/gnutls_buffers.c b/lib/gnutls_buffers.c
index 8d9be9c..f21c57a 100644
--- a/lib/gnutls_buffers.c
+++ b/lib/gnutls_buffers.c
@@ -318,6 +318,10 @@ _gnutls_read (gnutls_session_t session, void *iptr,
 	      int tmperr = WSAGetLastError();
 	      switch (tmperr)
 		{
+		case WSAETIMEDOUT:
+		  gnutls_assert();
+		  /* fall through */
+
 		case WSAEWOULDBLOCK:
 		  session->internals.errnum = EAGAIN;
 		  break;

This triggers a debug message when debugging is enabled, which may help
people notice that something may be fishy in the recv functions, and
possibly even trace it back to this e-mail.

> FYI: The root cause for the problem was that libsoup uses setsockopt's
> SO_RCVTIMEO and SO_SNDTIMEO options to set the socket's timeout,
> passing a pointer to a struct timeval, like on Unix. But... the
> Winsock designers, for some reason, decided to change the semantics of
> these options: In Winsock the option value is an int, the timeout in
> milliseconds. So when libsoup tried to set the timeout to 30 seconds,
> it actually set it to 30 milliseconds, eek.) What on Earth were they
> thinking when they changed the type of the option value for
> SO_RCVTIMEO and SO_SNDTIMEO like this? They should at least have used
> a different names for the options when they change the type of their
> values. The type unsafety of setsockopt() means the compiler can't
> warn either.

Sigh.

/Simon




From tml at iki.fi  Wed Jun  4 16:40:57 2008
From: tml at iki.fi (Tor Lillqvist)
Date: Wed, 4 Jun 2008 17:40:57 +0300
Subject: Suggested fix on Windows: handle also WSAETIMEDOUT after recv()
	returns failure
In-Reply-To: <87abi15m7e.fsf@mocca.josefsson.org>
References: <c9b6d9a50806040604n7d309ba0v999db8d395fbbbe3@mail.gmail.com>
	<87abi15m7e.fsf@mocca.josefsson.org>
Message-ID: <c9b6d9a50806040740y42e0baf6y90d9a30f641e165a@mail.gmail.com>

> According to MSDN, WSAETIMEDOUT means the connection has been "dropped":

>  "The connection has been dropped because of a network failure or
>  because the peer system failed to respond."

That is clearly only half a truth, the MSDN doc for SO_RCVTIMEO under
setsockopt() says that

"In Windows 2000 and later, if no data arrives within the period
specified in SO_RCVTIMEO the recv function returns WSAETIMEDOUT, and
if data is received, recv returns SUCCESS."

so that case should also be mentioned on the recv() doc for WSAETIMEDOUT.

But, it also warns that "If a send or receive operation times out on a
socket, the socket state is indeterminate, and should not be used; TCP
sockets in this state have a potential for data loss, since the
operation could be canceled at the same moment the operation was to be
completed." which sounds a bit alarming... MSDN documentation can be
misleading and contradictory at times.

(http://msdn.microsoft.com/en-us/library/ms740476(VS.85).aspx )

> Are you saying that calling recv again after a WSAETIMEDOUT actually
> results in data sooner or later?

At least that is what I saw in my (not very systematic, I admit) test
under gdb... I guess more experimentation is called for.

--tml




From joe at manyfish.co.uk  Wed Jun  4 16:53:20 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 4 Jun 2008 15:53:20 +0100
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <87ej7d5mr6.fsf@mocca.josefsson.org>
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080604104254.GA20298@manyfish.co.uk>
	<87ej7d5mr6.fsf@mocca.josefsson.org>
Message-ID: <20080604145320.GB21148@manyfish.co.uk>

On Wed, Jun 04, 2008 at 03:54:21PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> > Having looked into this, I can't see why that would break.  dlsym() will 
> > still find the symbols since libgnutls-extra.so is linked against 
> > libgnutls; the wording in POSIX is very specific that this must be the 
> > case.  Attached a test case which finds gnutls_malloc via dlopen of 
> > libgnutls-extra.so for PoC.
> >
> > So I think it's very reasonable to argue that the ABI of libgnutls-extra 
> > has not changed in this case and no soname bump is necessary.
> 
> But what about non-ELF or even systems without shared libraries?

The dlsym wording is from POSIX; the only platforms I'd expect it might 
be different are the few Unixes with only pre-POSIX dynamic loaders 
(AIX, HPUX).  This libtool -version-info choice doesn't make any 
difference for static library builds on any platform AFAIK.

> Possibly we could decide that systems that doesn't behave like Linux
> here are of too little concern to us, and that they will need to remove
> the old libgnutls* when they install gnutls 2.4.x.

I'm not sure why that's a concern, trying to mix and match libgnutls and 
libgnutls-extra from different versions would not be guarnateed to work 
anyway, surely?  (e.g. libgnutls-extra from 2.4 could depend on 
libgnutls symbols introduced in 2.4; soname versioning would not prevent 
the former being used with 2.2, current concens aside)

Regards,

joe




From nmav at gnutls.org  Wed Jun  4 18:57:45 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 04 Jun 2008 19:57:45 +0300
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <87y75lanr5.fsf@mocca.josefsson.org>
References: <20080525080428.GB3208@downhill.g.la>	<4842D055.2020002@gnutls.org>
	<20080602172252.GB3060@downhill.g.la>	<4844517A.3030002@gnutls.org>
	<87y75lanr5.fsf@mocca.josefsson.org>
Message-ID: <4846C989.7040906@gnutls.org>

Simon Josefsson wrote:

> FWIW, this seems to happen on my system as well, a normal x86 debian
> box.  Does it work on your machine?  There are valgrind errors, see
> below.

> ==18506== Use of uninitialised value of size 4
> ==18506==    at 0x4181141: (within /lib/i686/cmov/libc-2.7.so)
> ==18506==    by 0x4183079: vfprintf (in /lib/i686/cmov/libc-2.7.so)
> ==18506==    by 0x41A0E9B: vsprintf (in /lib/i686/cmov/libc-2.7.so)
> ==18506==    by 0x418B24D: sprintf (in /lib/i686/cmov/libc-2.7.so)
> ==18506==    by 0x40600D6: _gnutls_bin2hex (gnutls_str.c:265)
> ==18506==    by 0x406E19E: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:731)

This one looks quite strange. Does the openpgpself fail to your system
as well? Does it still fail with my latest commit?

I'm afraid that when the gnutls_openpgp_keyid_t is passed on the stack
it has a pointer status, thus the sizeof() returns 4 instead of 8.
If I'm correct then my latest commit should fix this issue.

regards,
Nikos




From ametzler at downhill.at.eu.org  Wed Jun  4 19:58:22 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 4 Jun 2008 19:58:22 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4846C989.7040906@gnutls.org>
References: <20080525080428.GB3208@downhill.g.la> <4842D055.2020002@gnutls.org>
	<20080602172252.GB3060@downhill.g.la> <4844517A.3030002@gnutls.org>
	<87y75lanr5.fsf@mocca.josefsson.org> <4846C989.7040906@gnutls.org>
Message-ID: <20080604175822.GA3633@downhill.g.la>

On 2008-06-04 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> I'm afraid that when the gnutls_openpgp_keyid_t is passed on the stack
> it has a pointer status, thus the sizeof() returns 4 instead of 8.
> If I'm correct then my latest commit should fix this issue.

commit 12376a5162ad880bd500438f479167054678b366 indeed seems to fix
the build failure on sparc. (log of test attached)

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'
-------------- next part --------------
PASS: resume
client |<2>| Importing Openpgp key and using openpgp sub key: 837b6fb42e0fe176
client |<2>| Importing Openpgp cert and using openpgp sub key: 837b6fb42e0fe176
client |<2>| ASSERT: pgp.c:156
client |<2>| ASSERT: privkey.c:1058
client |<2>| Importing Openpgp key and using main openpgp key.
client |<2>| ASSERT: pgp.c:1461
client |<2>| Importing Openpgp cert and using main openpgp key
client |<2>| ASSERT: pgp.c:156
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
client |<2>| EXT[43df0]: Sending extension CERT_TYPE
client |<3>| HSK[43df0]: CLIENT HELLO was send [88 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[0] Handshake(22) with length: 88
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 93 bytes to 5.
client |<7>| WRITE: wrote 93 bytes to 5. Left 0 bytes. Total 93 bytes.
client |<7>| 0000 - 16 03 02 00 58 01 00 00 54 03 02 48 46 d2 28 69 
client |<7>| 0001 - 17 8f 54 c4 c8 99 3c 4e 7e 4f a1 56 1f 18 27 50 
client |<7>| 0002 - 92 67 93 fd 86 ed ee 6a a0 90 cb 00 00 24 00 33 
client |<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
client |<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 
client |<7>| 0005 - 00 04 01 00 00 07 00 09 00 03 02 00 01 
client |<4>| REC[43df0]: Sent Packet[1] Handshake(22) with length: 93
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 00 58 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[0] Handshake(22) with length: 88
server |<7>| READ: Got 88 bytes from 5
server |<7>| READ: read 88 bytes from 5
server |<7>| 0000 - 01 00 00 54 03 02 48 46 d2 28 69 17 8f 54 c4 c8 
server |<7>| 0001 - 99 3c 4e 7e 4f a1 56 1f 18 27 50 92 67 93 fd 86 
server |<7>| 0002 - ed ee 6a a0 90 cb 00 00 24 00 33 00 45 00 39 00 
server |<7>| 0003 - 88 00 16 00 32 00 44 00 38 00 87 00 13 00 66 00 
server |<7>| 0004 - 2f 00 41 00 35 00 84 00 0a 00 05 00 04 01 00 00 
server |<7>| 0005 - 07 00 09 00 03 02 00 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 88 bytes.
server |<7>| RB: Requested 93 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: Decrypted Packet[0] Handshake(22) with length: 88
server |<6>| BUF[HSK]: Inserted 88 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: CLIENT HELLO was received [88 bytes]
server |<6>| BUF[REC][HD]: Read 84 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 84 bytes of Data
server |<3>| HSK[43618]: Client's version: 3.2
server |<2>| ASSERT: gnutls_db.c:238
server |<2>| EXT[43618]: Received extension 'CERT_TYPE/9'
server |<2>| EXT[43618]: Received extension 'CERT_TYPE/9'
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: gnutls_x509.c:1077
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_ARCFOUR_MD5
server |<3>| HSK[43618]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Selected Compression Method: NULL
server |<2>| EXT[43618]: Sending extension CERT_TYPE
server |<3>| HSK[43618]: SessionID: 5c1b5184ca89f60f689e5a739e004be966a90d8e27746b2d989afc4e1ffbe20e
server |<3>| HSK[43618]: SERVER HELLO was send [81 bytes]
server |<6>| BUF[HSK]: Peeked 88 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[0] Handshake(22) with length: 81
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 86 bytes to 5.
server |<7>| WRITE: wrote 86 bytes to 5. Left 0 bytes. Total 86 bytes.
server |<7>| 0000 - 16 03 02 00 51 02 00 00 4d 03 02 48 46 d2 28 ea 
server |<7>| 0001 - c2 f5 ff e6 19 4b de 55 15 fb bf 06 d1 6a 42 f0 
server |<7>| 0002 - 1a 74 f4 dc 07 be 5c 51 b2 23 eb 20 5c 1b 51 84 
server |<7>| 0003 - ca 89 f6 0f 68 9e 5a 73 9e 00 4b e9 66 a9 0d 8e 
server |<7>| 0004 - 27 74 6b 2d 98 9a fc 4e 1f fb e2 0e 00 33 00 00 
server |<7>| 0005 - 05 00 09 00 01 01 
server |<4>| REC[43618]: Sent Packet[1] Handshake(22) with length: 86
server |<3>| HSK[43618]: CERTIFICATE was send [1046 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[1] Handshake(22) with length: 1046
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 1051 bytes to 5.
server |<7>| WRITE: wrote 1051 bytes to 5. Left 0 bytes. Total 1051 bytes.
server |<7>| 0000 - 16 03 02 04 16 0b 00 04 12 00 04 0f 02 08 83 7b 
server |<7>| 0001 - 6f b4 2e 0f e1 76 00 04 02 99 00 d1 04 47 63 e8 
server |<7>| 0002 - 83 01 06 20 d7 48 47 8b b9 3d 1e 12 c0 00 d6 c2 
server |<7>| 0003 - 3f f3 b6 0b 68 8b b5 d5 6e 69 5f 6d 04 c7 a4 16 
server |<7>| 0004 - 05 c5 34 82 f3 ca 48 49 23 72 57 fa e0 9e 5a ae 
server |<7>| 0005 - 9d 83 fb ec 5e da 1c be 0a 51 17 8d de ff 6c 2b 
server |<7>| 0006 - 0d 35 c5 21 84 7e 8c 7f 26 69 6a 51 48 3a 09 5b 
server |<7>| 0007 - d3 8d d7 8b 7e 4b 95 20 19 c7 8f ed 8a 32 56 b1 
server |<7>| 0008 - 7b 3a 7b 23 1b 4f 69 35 e9 5d c4 9f f2 23 ae 56 
server |<7>| 0009 - ae d4 5f ba 7a b4 a6 e9 a4 a5 ce e4 68 26 7c 0f 
server |<7>| 000a - 3c 55 45 6f 18 1b 35 fc f4 29 58 a4 1d 1a b8 fe 
server |<7>| 000b - e8 8d d1 46 60 cd fe 19 da d6 31 94 fc dd b7 db 
server |<7>| 000c - 7d 07 6f 1f 9b bb b8 3d 72 f8 a2 4a 1d 74 ae 2e 
server |<7>| 000d - eb 74 38 55 27 ae ed 46 44 46 52 cc b7 5c ee 9d 
server |<7>| 000e - 58 2e c4 9b 36 65 10 ef 00 11 01 00 01 b4 10 74 
server |<7>| 000f - 65 73 74 33 2e 67 6e 75 74 6c 73 2e 6f 72 67 c2 
server |<7>| 0010 - c0 40 04 13 01 02 00 26 05 02 47 63 e8 83 02 1b 
server |<7>| 0011 - 03 05 09 09 66 01 80 06 0b 09 08 07 03 02 04 15 
server |<7>| 0012 - 02 08 03 04 16 02 03 01 02 1e 01 02 17 80 00 0a 
server |<7>| 0013 - 09 10 a0 21 e3 f8 08 99 90 51 f7 a4 06 1f 71 37 
server |<7>| 0014 - cf 29 c4 4e e4 12 df ef a1 18 cb cc 5e ad a6 0c 
server |<7>| 0015 - 97 93 d9 ef 3d eb 8c bf 89 f2 0e 06 9a f6 2b 68 
server |<7>| 0016 - ac b8 b6 27 ae d1 8a cb 18 be 66 9b 72 1e fe b2 
server |<7>| 0017 - 99 1d db 0e f8 a8 e7 47 23 9e 84 ff 58 ad 68 9e 
server |<7>| 0018 - 8b 0e 26 fb 62 8c 60 52 f9 4f e8 a2 ad e2 9b b1 
server |<7>| 0019 - 31 a5 e4 18 5d cf f3 a5 8b 17 3a 60 79 9b a0 6f 
server |<7>| 001a - 76 89 94 a7 63 cc a9 dc 6c 98 e3 e8 69 19 12 63 
server |<7>| 001b - 1e 51 d9 19 68 ff 3d dc b2 87 65 ea ca 77 93 8e 
server |<7>| 001c - b9 63 f8 e0 ec be 20 93 10 f3 5c 93 3e 09 2d 71 
server |<7>| 001d - 32 17 0e 17 48 01 86 9a 6a 2e 71 ba ef 1d 28 c3 
server |<7>| 001e - ce 3b 3f 27 6c b7 39 30 d2 c3 aa 79 d9 0b 3e e4 
server |<7>| 001f - 9c 68 73 67 94 05 90 ed 01 fa 99 b6 e9 a8 72 70 
server |<7>| 0020 - 7a 44 ce 8d 04 47 88 a5 7c 01 04 00 d2 26 7c d5 
server |<7>| 0021 - 65 f2 a4 b2 38 64 4d be 85 87 c1 0a 77 cc 55 f4 
server |<7>| 0022 - 05 fe f3 e0 bc 04 b1 87 0a e2 18 36 bd 65 cd 9f 
server |<7>| 0023 - fd 57 da 91 f3 62 c1 98 07 1f a8 82 7a 9a 47 06 
server |<7>| 0024 - 23 f6 8e 58 e7 6e e3 ac 2f a7 f5 47 ed 05 b2 7c 
server |<7>| 0025 - 93 57 01 db b8 45 3b 21 4d b2 f8 9d 3f b3 4c f7 
server |<7>| 0026 - c1 cc 7d b3 1f 13 ed ba cf e7 3e 45 da 17 5a 80 
server |<7>| 0027 - 1b 03 f5 81 46 0a 27 c7 0c 01 1e c3 89 a6 02 2b 
server |<7>| 0028 - 18 d2 2d 90 1d 52 2e 5c 91 63 e1 13 00 11 01 00 
server |<7>| 0029 - 01 c2 c0 c7 04 18 01 02 00 0f 05 02 47 88 a5 7c 
server |<7>| 002a - 02 1b 02 05 09 10 ea cf 80 00 a8 09 10 a0 21 e3 
server |<7>| 002b - f8 08 99 90 51 9d 20 04 19 01 02 00 06 05 02 47 
server |<7>| 002c - 88 a5 7c 00 0a 09 10 83 7b 6f b4 2e 0f e1 76 00 
server |<7>| 002d - 47 04 00 a0 23 84 ef 64 48 e1 3c 52 ec 04 38 a9 
server |<7>| 002e - 70 b1 62 fd 2d 45 12 90 72 63 73 f7 1a d1 ab 0b 
server |<7>| 002f - 01 ea f3 ac 7b 25 75 10 1c c0 26 d6 91 5c 41 04 
server |<7>| 0030 - 7c 92 c3 60 8b 16 3c e9 81 d5 e1 c1 1b 6c ca d3 
server |<7>| 0031 - 20 1d a6 a9 7c 03 db 8a 70 16 8c 23 c8 10 9c 76 
server |<7>| 0032 - 80 36 5e 66 74 e0 8b 80 d5 6d 99 f9 13 75 33 1c 
server |<7>| 0033 - 6c 8b eb d3 04 a1 7a f9 b7 eb e9 89 e9 90 15 df 
server |<7>| 0034 - e7 18 3f a1 fd 0d 80 ef aa 1d 82 f0 2b c9 1b d2 
server |<7>| 0035 - d5 2a 23 f1 b7 06 1e 35 1f 95 ac 97 18 e4 af 68 
server |<7>| 0036 - 3f 0f d9 5e 55 cf 48 52 f3 64 19 72 a5 b1 0f ca 
server |<7>| 0037 - 94 06 a6 dc 07 c6 ad a2 49 8e 21 8c 61 2b 24 66 
server |<7>| 0038 - 3b 9f 13 e4 c6 be 89 ac 41 4d 42 30 79 ef a9 05 
server |<7>| 0039 - 80 e0 74 7e 84 d9 d8 7d c4 b9 70 c3 36 4a 68 27 
server |<7>| 003a - 08 44 24 1c 39 b9 0b b0 c5 68 7d 92 68 fa 6d 17 
server |<7>| 003b - 7f cc c8 e7 b3 5e 40 5f a1 5c 98 56 ee 52 2b 5a 
server |<7>| 003c - 04 15 af c2 15 a7 f9 60 a3 be 9a 70 b1 df 2f fb 
server |<7>| 003d - 75 9f 43 61 83 8a f6 b2 bc f6 7e 93 f6 c3 99 5a 
server |<7>| 003e - 43 4a 88 99 82 e7 66 11 85 1d 4f ab 25 4c 85 68 
server |<7>| 003f - 77 e1 0f cf ec bc dd 8b b9 99 0e e7 bd 29 8d 5f 
server |<7>| 0040 - ca eb c1 1a 1e 71 1f 93 96 fc 8d 6b bf 7a ea 21 
server |<7>| 0041 - c1 c0 b0 7f 6d 0c d6 44 e8 dc 18 
server |<4>| REC[43618]: Sent Packet[2] Handshake(22) with length: 1051
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 00 51 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[0] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[0] Handshake(22) with length: 81
client |<7>| READ: Got 81 bytes from 5
client |<7>| READ: read 81 bytes from 5
client |<7>| 0000 - 02 00 00 4d 03 02 48 46 d2 28 ea c2 f5 ff e6 19 
client |<7>| 0001 - 4b de 55 15 fb bf 06 d1 6a 42 f0 1a 74 f4 dc 07 
client |<7>| 0002 - be 5c 51 b2 23 eb 20 5c 1b 51 84 ca 89 f6 0f 68 
client |<7>| 0003 - 9e 5a 73 9e 00 4b e9 66 a9 0d 8e 27 74 6b 2d 98 
client |<7>| 0004 - 9a fc 4e 1f fb e2 0e 00 33 00 00 05 00 09 00 01 
client |<7>| 0005 - 01 
client |<7>| RB: Have 5 bytes into buffer. Adding 81 bytes.
client |<7>| RB: Requested 86 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[0] Handshake(22) with length: 81
client |<6>| BUF[HSK]: Inserted 81 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: SERVER HELLO was received [81 bytes]
client |<6>| BUF[REC][HD]: Read 77 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 77 bytes of Data
client |<3>| HSK[43df0]: Server's version: 3.2
client |<3>| HSK[43df0]: SessionID length: 32
client |<3>| HSK[43df0]: SessionID: 5c1b5184ca89f60f689e5a739e004be966a90d8e27746b2d989afc4e1ffbe20e
client |<3>| HSK[43df0]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
client |<2>| EXT[43df0]: Received extension 'CERT_TYPE/9'
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 04 16 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[1] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[1] Handshake(22) with length: 1046
client |<7>| READ: Got 1046 bytes from 5
client |<7>| READ: read 1046 bytes from 5
client |<7>| 0000 - 0b 00 04 12 00 04 0f 02 08 83 7b 6f b4 2e 0f e1 
client |<7>| 0001 - 76 00 04 02 99 00 d1 04 47 63 e8 83 01 06 20 d7 
client |<7>| 0002 - 48 47 8b b9 3d 1e 12 c0 00 d6 c2 3f f3 b6 0b 68 
client |<7>| 0003 - 8b b5 d5 6e 69 5f 6d 04 c7 a4 16 05 c5 34 82 f3 
client |<7>| 0004 - ca 48 49 23 72 57 fa e0 9e 5a ae 9d 83 fb ec 5e 
client |<7>| 0005 - da 1c be 0a 51 17 8d de ff 6c 2b 0d 35 c5 21 84 
client |<7>| 0006 - 7e 8c 7f 26 69 6a 51 48 3a 09 5b d3 8d d7 8b 7e 
client |<7>| 0007 - 4b 95 20 19 c7 8f ed 8a 32 56 b1 7b 3a 7b 23 1b 
client |<7>| 0008 - 4f 69 35 e9 5d c4 9f f2 23 ae 56 ae d4 5f ba 7a 
client |<7>| 0009 - b4 a6 e9 a4 a5 ce e4 68 26 7c 0f 3c 55 45 6f 18 
client |<7>| 000a - 1b 35 fc f4 29 58 a4 1d 1a b8 fe e8 8d d1 46 60 
client |<7>| 000b - cd fe 19 da d6 31 94 fc dd b7 db 7d 07 6f 1f 9b 
client |<7>| 000c - bb b8 3d 72 f8 a2 4a 1d 74 ae 2e eb 74 38 55 27 
client |<7>| 000d - ae ed 46 44 46 52 cc b7 5c ee 9d 58 2e c4 9b 36 
client |<7>| 000e - 65 10 ef 00 11 01 00 01 b4 10 74 65 73 74 33 2e 
client |<7>| 000f - 67 6e 75 74 6c 73 2e 6f 72 67 c2 c0 40 04 13 01 
client |<7>| 0010 - 02 00 26 05 02 47 63 e8 83 02 1b 03 05 09 09 66 
client |<7>| 0011 - 01 80 06 0b 09 08 07 03 02 04 15 02 08 03 04 16 
client |<7>| 0012 - 02 03 01 02 1e 01 02 17 80 00 0a 09 10 a0 21 e3 
client |<7>| 0013 - f8 08 99 90 51 f7 a4 06 1f 71 37 cf 29 c4 4e e4 
client |<7>| 0014 - 12 df ef a1 18 cb cc 5e ad a6 0c 97 93 d9 ef 3d 
client |<7>| 0015 - eb 8c bf 89 f2 0e 06 9a f6 2b 68 ac b8 b6 27 ae 
client |<7>| 0016 - d1 8a cb 18 be 66 9b 72 1e fe b2 99 1d db 0e f8 
client |<7>| 0017 - a8 e7 47 23 9e 84 ff 58 ad 68 9e 8b 0e 26 fb 62 
client |<7>| 0018 - 8c 60 52 f9 4f e8 a2 ad e2 9b b1 31 a5 e4 18 5d 
client |<7>| 0019 - cf f3 a5 8b 17 3a 60 79 9b a0 6f 76 89 94 a7 63 
client |<7>| 001a - cc a9 dc 6c 98 e3 e8 69 19 12 63 1e 51 d9 19 68 
client |<7>| 001b - ff 3d dc b2 87 65 ea ca 77 93 8e b9 63 f8 e0 ec 
client |<7>| 001c - be 20 93 10 f3 5c 93 3e 09 2d 71 32 17 0e 17 48 
client |<7>| 001d - 01 86 9a 6a 2e 71 ba ef 1d 28 c3 ce 3b 3f 27 6c 
client |<7>| 001e - b7 39 30 d2 c3 aa 79 d9 0b 3e e4 9c 68 73 67 94 
client |<7>| 001f - 05 90 ed 01 fa 99 b6 e9 a8 72 70 7a 44 ce 8d 04 
client |<7>| 0020 - 47 88 a5 7c 01 04 00 d2 26 7c d5 65 f2 a4 b2 38 
client |<7>| 0021 - 64 4d be 85 87 c1 0a 77 cc 55 f4 05 fe f3 e0 bc 
client |<7>| 0022 - 04 b1 87 0a e2 18 36 bd 65 cd 9f fd 57 da 91 f3 
client |<7>| 0023 - 62 c1 98 07 1f a8 82 7a 9a 47 06 23 f6 8e 58 e7 
client |<7>| 0024 - 6e e3 ac 2f a7 f5 47 ed 05 b2 7c 93 57 01 db b8 
client |<7>| 0025 - 45 3b 21 4d b2 f8 9d 3f b3 4c f7 c1 cc 7d b3 1f 
client |<7>| 0026 - 13 ed ba cf e7 3e 45 da 17 5a 80 1b 03 f5 81 46 
client |<7>| 0027 - 0a 27 c7 0c 01 1e c3 89 a6 02 2b 18 d2 2d 90 1d 
client |<7>| 0028 - 52 2e 5c 91 63 e1 13 00 11 01 00 01 c2 c0 c7 04 
client |<7>| 0029 - 18 01 02 00 0f 05 02 47 88 a5 7c 02 1b 02 05 09 
client |<7>| 002a - 10 ea cf 80 00 a8 09 10 a0 21 e3 f8 08 99 90 51 
client |<7>| 002b - 9d 20 04 19 01 02 00 06 05 02 47 88 a5 7c 00 0a 
client |<7>| 002c - 09 10 83 7b 6f b4 2e 0f e1 76 00 47 04 00 a0 23 
client |<7>| 002d - 84 ef 64 48 e1 3c 52 ec 04 38 a9 70 b1 62 fd 2d 
client |<7>| 002e - 45 12 90 72 63 73 f7 1a d1 ab 0b 01 ea f3 ac 7b 
client |<7>| 002f - 25 75 10 1c c0 26 d6 91 5c 41 04 7c 92 c3 60 8b 
client |<7>| 0030 - 16 3c e9 81 d5 e1 c1 1b 6c ca d3 20 1d a6 a9 7c 
client |<7>| 0031 - 03 db 8a 70 16 8c 23 c8 10 9c 76 80 36 5e 66 74 
client |<7>| 0032 - e0 8b 80 d5 6d 99 f9 13 75 33 1c 6c 8b eb d3 04 
client |<7>| 0033 - a1 7a f9 b7 eb e9 89 e9 90 15 df e7 18 3f a1 fd 
client |<7>| 0034 - 0d 80 ef aa 1d 82 f0 2b c9 1b d2 d5 2a 23 f1 b7 
client |<7>| 0035 - 06 1e 35 1f 95 ac 97 18 e4 af 68 3f 0f d9 5e 55 
client |<7>| 0036 - cf 48 52 f3 64 19 72 a5 b1 0f ca 94 06 a6 dc 07 
client |<7>| 0037 - c6 ad a2 49 8e 21 8c 61 2b 24 66 3b 9f 13 e4 c6 
client |<7>| 0038 - be 89 ac 41 4d 42 30 79 ef a9 05 80 e0 74 7e 84 
client |<7>| 0039 - d9 d8 7d c4 b9 70 c3 36 4a 68 27 08 44 24 1c 39 
client |<7>| 003a - b9 0b b0 c5 68 7d 92 68 fa 6d 17 7f cc c8 e7 b3 
client |<7>| 003b - 5e 40 5f a1 5c 98 56 ee 52 2b 5a 04 15 af c2 15 
client |<7>| 003c - a7 f9 60 a3 be 9a 70 b1 df 2f fb 75 9f 43 61 83 
client |<7>| 003d - 8a f6 b2 bc f6 7e 93 f6 c3 99 5a 43 4a 88 99 82 
client |<7>| 003e - e7 66 11 85 1d 4f ab 25 4c 85 68 77 e1 0f cf ec 
client |<7>| 003f - bc dd 8b b9 99 0e e7 bd 29 8d 5f ca eb c1 1a 1e 
client |<7>| 0040 - 71 1f 93 96 fc 8d 6b bf 7a ea 21 c1 c0 b0 7f 6d 
client |<7>| 0041 - 0c d6 44 e8 dc 18 
client |<7>| RB: Have 5 bytes into buffer. Adding 1046 bytes.
client |<7>| RB: Requested 1051 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[1] Handshake(22) with length: 1046
client |<6>| BUF[HSK]: Inserted 1046 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: CERTIFICATE was received [1046 bytes]
client |<6>| BUF[REC][HD]: Read 1042 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 81 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 1042 bytes of Data
client |<2>| Importing Openpgp cert and using openpgp sub key: 837b6fb42e0fe176
client |<2>| ASSERT: pgp.c:156
server |<3>| HSK[43618]: SERVER KEY EXCHANGE was send [397 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[2] Handshake(22) with length: 397
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 402 bytes to 5.
server |<7>| WRITE: wrote 402 bytes to 5. Left 0 bytes. Total 402 bytes.
server |<7>| 0000 - 16 03 02 01 8d 0c 00 01 89 00 80 b6 4c 70 da 39 
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 01 8d 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
 f3 61 b2 e6 c6 2d 86 42 ff 6c fc f4 06 58 
server |<7>| 0003 - fd 5d f6 2d b6 3f 60 e9 ad f7 09 92 75 ad ec a8 
client |<4>| REC[43df0]: Expected Packet[2] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[2] Handshake(22) with length: 397
client |<7>| READ: Got 397 bytes from 5
server |<7>| 0005 - 22 91 92 71 6f ef 4b c9 21 af 0d 2b 95 08 b2 78 
server |<7>| 0006 - 2b d0 80 5d ce 19 e1 8e 13 2c 1c c3 ea 10 4f 84 
client |<7>| 0000 - 0c 00 01 89 00 80 b6 4c 70 da 39 6c 54 2b 2b 7c 
client |<7>| 0001 - ba b1 ac df 88 ac 5f f7 5b cb d5 16 f0 f3 61 b2 
server |<7>| 0007 - a6 14 e0 fb 1f 4b 26 25 ed 82 37 28 d8 a5 ec 41 
server |<7>| 0008 - 5d 0f c0 d2 66 d3 17 d4 0a 9b 57 00 01 05 00 80 
client |<7>| 0002 - e6 c6 2d 86 42 ff 6c fc f4 06 58 fd 5d f6 2d b6 
client |<7>| 0003 - 3f 60 e9 ad f7 09 92 75 ad ec a8 42 23 54 9a 62 
server |<7>| 0009 - 24 81 32 b4 8e 3e 96 02 27 38 09 76 61 be 01 c3 
server |<7>| 000a - e0 4e 24 cb 56 18 5e 33 d2 fa ee f2 90 82 60 85 
client |<7>| 0004 - c7 8e 40 82 08 01 83 fb f0 27 f2 22 91 92 71 6f 
server |<7>| 000b - c8 2d 4a bc c7 0a c9 db c9 8e 7e d1 9e 29 2c 01 
server |<7>| 000c - 50 ec c1 b2 cb f6 4f 1e 60 13 47 40 e4 88 96 cc 
client |<7>| 0006 - 19 e1 8e 13 2c 1c c3 ea 10 4f 84 a6 14 e0 fb 1f 
server |<7>| 000d - e0 aa 8f d4 de 65 73 25 ee 41 d2 cb e3 29 ce bb 
server |<7>| 000e - 7a a5 48 62 26 5a ce 10 9a 98 bc 78 11 6c 7d c4 
client |<7>| 0008 - d3 17 d4 0a 9b 57 00 01 05 00 80 24 81 32 b4 8e 
server |<7>| 000f - 04 9b 43 2d 1a 36 a8 52 48 9a 53 de 63 12 86 d1 
client |<7>| 000a - 18 5e 33 d2 fa ee f2 90 82 60 85 c8 2d 4a bc c7 
client |<7>| 000b - 0a c9 db c9 8e 7e d1 9e 29 2c 01 50 ec c1 b2 cb 
client |<7>| 000c - f6 4f 1e 60 13 47 40 e4 88 96 cc e0 aa 8f d4 de 
client |<7>| 000d - 65 73 25 ee 41 d2 cb e3 29 ce bb 7a a5 48 62 26 
server |<7>| 0012 - 49 25 09 5b cc e0 e0 72 df a4 0f fc 52 43 f9 30 
server |<7>| 0013 - c9 b9 42 88 39 b3 bf 24 42 31 7c 91 d6 48 69 02 
client |<7>| 000e - 5a ce 10 9a 98 bc 78 11 6c 7d c4 04 9b 43 2d 1a 
client |<7>| 000f - 36 a8 52 48 9a 53 de 63 12 86 d1 94 85 34 e0 10 
server |<7>| 0014 - d6 ce 7f 58 ac 1a 3a e9 e7 19 76 3a 0e 37 c9 f7 
server |<7>| 0015 - de b6 6a 93 7c ff ff 8f aa 9e d0 17 d1 cf b4 05 
client |<7>| 0010 - 54 64 c6 fb 36 e0 71 0a c8 5e ef 00 80 56 1b b5 
client |<7>| 0011 - 8e 54 ad 8d 69 17 32 53 29 b0 86 49 25 09 5b cc 
server |<7>| 0016 - 29 92 46 9d 39 51 fe a0 7f d7 e3 e9 3e 30 ae cc 
server |<7>| 0017 - e1 1c 83 be 26 92 55 83 03 06 ed 9c 2d b3 08 43 
client |<7>| 0012 - e0 e0 72 df a4 0f fc 52 43 f9 30 c9 b9 42 88 39 
client |<7>| 0013 - b3 bf 24 42 31 7c 91 d6 48 69 02 d6 ce 7f 58 ac 
server |<7>| 0018 - 76 ba d9 ae 4b cd 4b 76 ea 67 76 ea 9b 1c 4d f3 
server |<7>| 0019 - c8 9c 
server |<4>| REC[43618]: Sent Packet[3] Handshake(22) with length: 402
server |<3>| HSK[43618]: CERTIFICATE REQUEST was send [9 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[3] Handshake(22) with length: 9
server |<2>| ASSERT: gnutls_cipher.c:205
d1 cf b4 05 29 92 46 9d 39 
client |<7>| 0016 - 51 fe a0 7f d7 e3 e9 3e 30 ae cc e1 1c 83 be 26 
client |<7>| 0017 - 92 55 83 03 06 ed 9c 2d b3 08 43 76 ba d9 ae 4b 
client |<7>| 0018 - cd 4b 76 ea 67 76 ea 9b 1c 4d f3 c8 9c 
client |<7>| RB: Have 5 bytes into buffer. Adding 397 bytes.
client |<7>| RB: Requested 402 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[2] Handshake(22) with length: 397
client |<6>| BUF[HSK]: Inserted 397 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<7>| 0000 - 16 03 02 00 09 0d 00 00 05 02 01 02 00 00 
server |<4>| REC[43618]: Sent Packet[4] Handshake(22) with length: 14
server |<3>| HSK[43618]: SERVER HELLO DONE was send [4 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[4] Handshake(22) with length: 4
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 9 bytes to 5.
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 393 bytes of Data
server |<7>| WRITE: wrote 9 bytes to 5. Left 0 bytes. Total 9 bytes.
server |<7>| 0000 - 16 03 02 00 04 0e 00 00 00 
server |<4>| REC[43618]: Sent Packet[5] Handshake(22) with length: 9
client |<2>| Importing Openpgp cert and using openpgp sub key: 837b6fb42e0fe176
client |<2>| ASSERT: pgp.c:156
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 00 09 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[3] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[3] Handshake(22) with length: 9
client |<7>| READ: Got 9 bytes from 5
client |<7>| READ: read 9 bytes from 5
client |<7>| 0000 - 0d 00 00 05 02 01 02 00 00 
client |<7>| RB: Have 5 bytes into buffer. Adding 9 bytes.
client |<7>| RB: Requested 14 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[3] Handshake(22) with length: 9
client |<6>| BUF[HSK]: Inserted 9 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: CERTIFICATE REQUEST was received [9 bytes]
client |<6>| BUF[REC][HD]: Read 5 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 397 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 5 bytes of Data
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 00 04 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[4] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[4] Handshake(22) with length: 4
client |<7>| READ: Got 4 bytes from 5
client |<7>| READ: read 4 bytes from 5
client |<7>| 0000 - 0e 00 00 00 
client |<7>| RB: Have 5 bytes into buffer. Adding 4 bytes.
client |<7>| RB: Requested 9 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[4] Handshake(22) with length: 4
client |<6>| BUF[HSK]: Inserted 4 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: SERVER HELLO DONE was received [4 bytes]
client |<6>| BUF[HSK]: Peeked 9 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<3>| HSK[43df0]: CERTIFICATE was send [566 bytes]
client |<6>| BUF[HSK]: Peeked 4 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[1] Handshake(22) with length: 566
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 571 bytes to 5.
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 02 36 
client |<7>| 0000 - 16 03 02 02 36 0b 00 02 32 00 02 2f 01 server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[1] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[1] Handshake(22) with length: 566
server |<7>| READ: Got 566 bytes from 5
server |<7>| READ: read 566 bclient |<7>| 0002 - f8 28 06 fa 6f 4c 18 0b f1 f1 4f c0 10 2e 0f 4e 
client |<7>| 0003 - 15 60 51 2d 0b bf b8 a4 1a 7a 90 5b 07 8d 44 7b 
server |<7>| 0000 - 0b 00 02 32 00 02 2f 01 00 02 2b 99 01 a2 04 3c 
server |<7>| 0001 - 67 95 8d 11 04 00 80 b1 65 21 8b f8 28 06 fa 6f 
client |<7>| 0004 - 4d 35 24 06 c3 a4 d8 fb cc 1e b0 dd bf 4f 82 e3 
client |<7>| 0005 - 1d 82 1f c6 06 3f 57 be 3b 47 f6 c8 b5 a4 f1 4b 
server |<7>| 0002 - 4c 18 0b f1 f1 4f c0 10 2e 0f 4e 15 60 51 2d 0b 
server |<7>| 0003 - bf b8 a4 1a 7a 90 5b 07 8d 44 7b 4d 35 24 06 c3 
client |<7>| 0006 - be 92 41 75 db 28 aa 6d bb c3 12 20 9d 78 94 fa 
client |<7>| 0007 - 73 7b c8 b2 d6 3c bc 9f 49 b2 8e 60 fc b0 7c 5e 
server |<7>| 0004 - a4 d8 fb cc 1e b0 dd bf 4f 82 e3 1d 82 1f c6 06 
server |<7>| 0005 - 3f 57 be 3b 47 f6 c8 b5 a4 f1 4b be 92 41 75 db 
client |<7>| 0008 - 08 2a f3 c4 7b 8d 71 52 de 11 fe 58 2e 6f ff a3 
client |<7>| 0009 - fa 48 04 5f cd 79 78 e7 b7 15 7b 00 a0 bf 14 9f 
server |<7>| 0006 - 28 aa 6d bb c3 12 20 9d 78 94 fa 73 7b c8 b2 d6 
server |<7>| 0007 - 3c bc 9f 49 b2 8e 60 fc b0 7c 5e 08 2a f3 c4 7b 
client |<7>| 000a - 1a c9 bd 98 5a 2c a4 9d 01 dd 11 b2 83 93 01 d1 
client |<7>| 000b - df 03 fd 14 10 af 22 42 19 d4 76 9c b7 b8 55 f7 
server |<7>| 0008 - 8d 71 52 de 11 fe 58 2e 6f ff a3 fa 48 04 5f cd 
server |<7>| 0009 - 79 78 e7 b7 15 7b 00 a0 bf 14 9f 1a c9 bd 98 5a 
client |<7>| 000c - 2d 3c bd 90 04 3f f5 5e 1b 6e 6e a1 1b 7a d6 95 
client |<7>| 000d - 3f 1b 2c aa b2 5d 03 e7 a9 94 14 53 ed 41 e8 91 
server |<7>| 000a - 2c a4 9d 01 dd 11 b2 83 93 01 d1 df 03 fd 14 10 
server |<7>| 000b - af 22 42 19 d4 76 9c b7 b8 55 f7 2d 3c bd 90 04 
client |<7>| 000e - 20 5a 84 cf 20 99 29 8d b9 2a cb 0e e8 cf 7c 4b 
server |<7>| 000c - 3f f5 5e 1b 6e 6e a1 1b 7a d6 95 3f 1b 2c aa b2 
server |<7>| 000d - 5d 03 e7 a9 94 14 53 ed 41 e8 91 20 5a 84 cf 20 
client |<7>| 0010 - 64 81 f6 f4 a2 65 23 fa a4 d7 11 b8 2b b0 fa 07 
server |<7>| 000e - 99 29 8d b9 2a cb 0e e8 cf 7c 4b 5a 32 0e 98 22 
server |<7>| 000f - 40 7e 2a ad 15 78 92 c4 d1 c5 d3 64 81 f6 f4 a2 
client |<7>| 0012 - f0 dd fa d2 e2 35 5e 35 a4 19 34 74 95 a9 9f 3f 
client |<7>| 0013 - 56 63 8c 03 ff 6b 90 db 5c 71 0e 11 55 df 56 4c 
server |<7>| 0010 - 65 23 fa a4 d7 11 b8 2b b0 fa 07 47 0a 68 70 bf 
client |<7>| 0014 - 5a 07 2a f4 f8 bd f8 88 48 43 88 cc a1 a6 70 16 
client |<7>| 0015 - 3d 1f 29 aa ec c0 9c 8b 79 8d 7b 80 83 22 69 2f 
client |<7>| 0016 - 66 09 e3 0e 52 40 33 dd 42 5f 53 83 b6 13 cb 06 
server |<7>| 0013 - 6b 90 db 5c 71 0e 11 55 df 56 4c 5a 07 2a f4 f8 
server |<7>| 0014 - bd f8 88 48 43 88 cc a1 a6 70 16 3d 1f 29 aa ec 
client |<7>| 0017 - ab f2 86 73 21 87 10 e7 68 39 78 36 1e 36 b8 f3 
client |<7>| 0018 - 12 af d2 44 5b 62 30 a0 86 c5 9d ed 74 8a 11 93 
server |<7>| 0015 - c0 9c 8b 79 8d 7b 80 83 22 69 2f 66 09 e3 0e 52 
server |<7>| 0016 - 40 33 dd 42 5f 53 83 b6 13 cb 06 ab f2 86 73 21 
client |<7>| 0019 - 3b 89 41 4b 50 b6 f1 47 d2 18 43 26 ff c2 41 32 
server |<7>| 0017 - 87 10 e7 68 39 78 36 1e 36 b8 f3 12 af d2 44 5b 
server |<7>| 0018 - 62 30 a0 86 c5 9d ed 74 8a 11 93 3b 89 41 4b 50 
client |<7>| 001b - 95 a1 ee 62 e4 b4 25 44 72 2e 20 57 68 6f 20 28 
server |<7>| 0019 - b6 f1 47 d2 18 43 26 ff c2 41 32 dc 40 8d b6 32 
server |<7>| 001a - dc 16 33 52 d0 8c 03 e6 c6 04 6e 95 a1 ee 62 e4 
client |<7>| 001d - 6f 40 77 68 6f 69 73 2e 6f 72 67 3e c2 5d 04 13 
server |<7>| 001b - b4 25 44 72 2e 20 57 68 6f 20 28 4e 6f 20 63 6f 
server |<7>| 001c - 6d 6d 65 6e 74 73 29 20 3c 77 68 6f 40 77 68 6f 
client |<7>| 001f - 05 0b 07 0a 03 04 03 15 03 02 03 16 02 01 02 17 
server |<7>| 001d - 69 73 2e 6f 72 67 3e c2 5d 04 13 11 02 00 1d 05 
server |<7>| 001e - 02 3c 67 95 8d 05 09 03 c2 67 00 05 0b 07 0a 03 
client |<7>| 0021 - 9f 78 99 cb c9 f6 e9 4c 30 7b 98 38 77 68 04 db 
client |<7>| 0022 - fb 43 d7 cf 6f 00 a0 a4 5d 02 90 55 33 a0 6d cb 
server |<7>| 001f - 04 03 15 03 02 03 16 02 01 02 17 80 00 0a 09 10 
server |<7>| 0020 - 35 14 5c ea a7 d9 3c 3f 96 58 00 9f 78 99 cb c9 
client |<7>| 0023 - eb d6 c9 71 fa 1d f1 7a 65 38 fe 
client |<4>| REC[43df0]: Sent Packet[2] Handshake(22) with length: 571
server |<7>| 0021 - f6 e9 4c 30 7b 98 38 77 68 04 db fb 43 d7 cf 6f 
server |<7>| 0022 - 00 a0 a4 5d 02 90 55 33 a0 6d cb eb d6 c9 71 fa 
server |<7>| 0023 - 1d f1 7a 65 38 fe 
server |<7>| RB: Have 5 bytes into buffer. Adding 566 bytes.
server |<7>| RB: Requested 571 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: Decrypted Packet[1] Handshake(22) with length: 566
server |<6>| BUF[HSK]: Inserted 566 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: CERTIFICATE was received [566 bytes]
server |<6>| BUF[REC][HD]: Read 562 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 562 bytes of Data
server |<2>| ASSERT: pgp.c:1461
server |<2>| Importing Openpgp cert and using main openpgp key
server |<2>| ASSERT: pgp.c:156
client |<3>| HSK[43df0]: CLIENT KEY EXCHANGE was send [134 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[2] Handshake(22) with length: 134
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 139 bytes to 5.
client |<7>| WRITE: wrote 139 bytes to 5. Left 0 bytes. Total 139 bytes.
client |<7>| 0000 - 16 03 02 00 86 10 00 00 82 00 80 3b 8e 59 42 f0 
client |<7>| 0001 - c1 ab 6a 1f a8 61 b6 5f ec 0c 25 9a e3 4f 12 d9 
server |<4>| REC[43618]: Expected Packet[2] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[2] Handshake(22) with length: 134
server |<7>| READ: Got 134 bytes from 5
client |<7>| 0003 - 20 05 93 33 45 4c 27 dc ac 66 b1 0e f2 5d 92 46 
client |<7>| 0004 - 3b 94 ca 96 7e f9 ef 32 fe 82 4c 17 5e e8 dc 47 
server |<7>| 0000 - 10 00 00 82 00 80 3b 8e 59 42 f0 c1 ab 6a 1f a8 
client |<7>| 0005 - 4e 73 72 83 d2 15 48 5b 3d 04 35 c0 df ac 0c 60 
client |<7>| 0006 - cb 05 50 92 0b c5 7c 85 92 42 e6 9a 8c 6d 11 89 
server |<7>| 0002 - 9e 24 7c 4c 01 bb 02 c4 82 2e 9a 20 05 93 33 45 
server |<7>| 0003 - 4c 27 dc ac 66 b1 0e f2 5d 92 46 3b 94 ca 96 7e 
client |<7>| 0007 - 55 84 a4 64 25 a9 fa 0d b6 9a d3 3e 2b 81 48 3d 
client |<7>| 0008 - a7 17 23 77 2f b0 1d 74 4f 52 cb 
server |<7>| 0004 - f9 ef 32 fe 82 4c 17 5e e8 dc 47 4e 73 72 83 d2 
client |<4>| REC[43df0]: Sent Packet[3] Handshake(22) with length: 139
server |<7>| 0005 - 15 48 5b 3d 04 35 c0 df ac 0c 60 cb 05 50 92 0b 
server |<7>| 0006 - c5 7c 85 92 42 e6 9a 8c 6d 11 89 55 84 a4 64 25 
server |<7>| 0007 - a9 fa 0d b6 9a d3 3e 2b 81 48 3d a7 17 23 77 2f 
server |<7>| 0008 - b0 1d 74 4f 52 cb 
server |<7>| RB: Have 5 bytes into buffer. Adding 134 bytes.
server |<7>| RB: Requested 139 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: Decrypted Packet[2] Handshake(22) with length: 134
server |<6>| BUF[HSK]: Inserted 134 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: CLIENT KEY EXCHANGE was received [134 bytes]
server |<6>| BUF[REC][HD]: Read 130 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 566 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 130 bytes of Data
client |<3>| HSK[43df0]: CERTIFICATE VERIFY was send [52 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[3] Handshake(22) with length: 52
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 57 bytes to 5.
client |<7>| WRITE: wrote 57 bytes to 5. Left 0 bytes. Total 57 bytes.
client |<7>| 0000 - 16 03 02 00 34 0f 00 00 30 00 2e 30 2c 02 14 1c 
client |<7>| 0001 - aa 7b 98 f3 1d e7 c7 52 b9 e5 6f ca 68 b5 99 1f 
client |<7>| 0002 - a9 31 91 02 14 5e 07 23 3e ab d1 b5 74 41 a5 cf 
client |<7>| 0003 - e9 f9 db 31 e1 e9 be 47 e9 
client |<4>| REC[43df0]: Sent Packet[4] Handshake(22) with length: 57
client |<3>| REC[43df0]: Sent ChangeCipherSpec
client |<4>| REC[43df0]: Sending Packet[4] Change Cipher Spec(20) with length: 1
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 6 bytes to 5.
client |<7>| WRITE: wrote 6 bytes to 5. Left 0 bytes. Total 6 bytes.
client |<7>| 0000 - 14 03 02 00 01 01 
client |<4>| REC[43df0]: Sent Packet[5] Change Cipher Spec(20) with length: 6
client |<9>| INT: PREMASTER SECRET[128]: 610048f18b8567535ae2a7710123e0655488b991a00dbfd39cb4c15b4de18b9278c6062892ce1cc8c7b8668f1a795cbfa966d4faf97a391013a5571ca847479e83ad9a407648de206deaae8d2b1f42871b2ac1f9c6e94205529f98a05b1b6db531d0e8eca51d311dce6cb3f41246223a393c51a5ebcf5adae1ceef5b8eb5ce90
client |<9>| INT: CLIENT RANDOM[32]: 4846d22869178f54c4c8993c4e7e4fa1561f182750926793fd86edee6aa090cb
client |<9>| INT: SERVER RANDOM[32]: 4846d228eac2f5ffe6194bde5515fbbf06d16a42f01a74f4dc07be5c51b223eb
client |<9>| INT: MASTER SECRET: c5dea8b2bad6b9eae3efe681ed7ea24a988e2fea15b7aa9aeedb6c9c2d8fd6d5dbdb350ee2f0c6a167e9d80551257451
client |<9>| INT: KEY BLOCK[104]: ba6f3241ec0a7d7a59230294933bc75fc9314e09d78ef436e84398ae39419785
client |<9>| INT: CLIENT WRITE KEY [16]: d80156a8cc3620a4bbcee94b5c8beecd
client |<9>| INT: SERVER WRITE KEY [16]: 223e6aa47176a5aeec0b378b1f707e72
client |<3>| HSK[43df0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Initializing internal [write] cipher sessions
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<3>| HSK[43df0]: FINISHED was send [16 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[0] Handshake(22) with length: 16
client |<7>| WRITE: Will write 101 bytes to 5.
client |<7>| WRITE: wrote 101 bytes to 5. Left 0 bytes. Total 101 bytes.
client |<7>| 0000 - 16 03 02 00 60 a6 f9 f5 d0 f1 33 a4 f1 33 cc c4 
client |<7>| 0001 - 40 2e e0 b5 98 a5 91 d6 93 a5 2c 7b 65 53 36 f1 
client |<7>| 0002 - d9 0e b5 db 58 90 cd 94 4d 50 e4 64 d6 4c ff cf 
client |<7>| 0003 - b6 ac 9a 3c 90 c5 ae a8 0e 38 38 dc fb ed 31 d8 
client |<7>| 0004 - d2 80 11 f7 be 69 65 a2 cd 18 b7 9e 9d 4f 33 ab 
client |<7>| 0005 - 56 05 15 f0 12 0e b5 e3 05 b3 d1 4b c5 76 d8 fd 
client |<7>| 0006 - 0a 46 0d 62 64 
client |<4>| REC[43df0]: Sent Packet[1] Handshake(22) with length: 101
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 00 34 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[3] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[3] Handshake(22) with length: 52
server |<7>| READ: Got 52 bytes from 5
server |<7>| READ: read 52 bytes from 5
server |<7>| 0000 - 0f 00 00 30 00 2e 30 2c 02 14 1c aa 7b 98 f3 1d 
server |<7>| 0001 - e7 c7 52 b9 e5 6f ca 68 b5 99 1f a9 31 91 02 14 
server |<7>| 0002 - 5e 07 23 3e ab d1 b5 74 41 a5 cf e9 f9 db 31 e1 
server |<7>| 0003 - e9 be 47 e9 
server |<7>| RB: Have 5 bytes into buffer. Adding 52 bytes.
server |<7>| RB: Requested 57 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: Decrypted Packet[3] Handshake(22) with length: 52
server |<6>| BUF[HSK]: Inserted 52 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: CERTIFICATE VERIFY was received [52 bytes]
server |<6>| BUF[REC][HD]: Read 48 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 134 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 48 bytes of Data
server |<2>| ASSERT: pgp.c:1461
server |<2>| Importing Openpgp cert and using main openpgp key
server |<2>| ASSERT: pgp.c:156
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 14 03 02 00 01 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[4] Change Cipher Spec(20) with length: 1
server |<4>| REC[43618]: Received Packet[4] Change Cipher Spec(20) with length: 1
server |<7>| READ: Got 1 bytes from 5
server |<7>| READ: read 1 bytes from 5
server |<7>| 0000 - 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
server |<7>| RB: Requested 6 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: ChangeCipherSpec Packet was received
server |<9>| INT: PREMASTER SECRET[128]: 610048f18b8567535ae2a7710123e0655488b991a00dbfd39cb4c15b4de18b9278c6062892ce1cc8c7b8668f1a795cbfa966d4faf97a391013a5571ca847479e83ad9a407648de206deaae8d2b1f42871b2ac1f9c6e94205529f98a05b1b6db531d0e8eca51d311dce6cb3f41246223a393c51a5ebcf5adae1ceef5b8eb5ce90
server |<9>| INT: CLIENT RANDOM[32]: 4846d22869178f54c4c8993c4e7e4fa1561f182750926793fd86edee6aa090cb
server |<9>| INT: SERVER RANDOM[32]: 4846d228eac2f5ffe6194bde5515fbbf06d16a42f01a74f4dc07be5c51b223eb
server |<9>| INT: MASTER SECRET: c5dea8b2bad6b9eae3efe681ed7ea24a988e2fea15b7aa9aeedb6c9c2d8fd6d5dbdb350ee2f0c6a167e9d80551257451
server |<9>| INT: KEY BLOCK[104]: ba6f3241ec0a7d7a59230294933bc75fc9314e09d78ef436e84398ae39419785
server |<9>| INT: CLIENT WRITE KEY [16]: d80156a8cc3620a4bbcee94b5c8beecd
server |<9>| INT: SERVER WRITE KEY [16]: 223e6aa47176a5aeec0b378b1f707e72
server |<3>| HSK[43618]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Initializing internal [read] cipher sessions
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 00 60 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[0] Handshake(22) with length: 96
server |<7>| READ: Got 96 bytes from 5
server |<7>| READ: read 96 bytes from 5
server |<7>| 0000 - a6 f9 f5 d0 f1 33 a4 f1 33 cc c4 40 2e e0 b5 98 
server |<7>| 0001 - a5 91 d6 93 a5 2c 7b 65 53 36 f1 d9 0e b5 db 58 
server |<7>| 0002 - 90 cd 94 4d 50 e4 64 d6 4c ff cf b6 ac 9a 3c 90 
server |<7>| 0003 - c5 ae a8 0e 38 38 dc fb ed 31 d8 d2 80 11 f7 be 
server |<7>| 0004 - 69 65 a2 cd 18 b7 9e 9d 4f 33 ab 56 05 15 f0 12 
server |<7>| 0005 - 0e b5 e3 05 b3 d1 4b c5 76 d8 fd 0a 46 0d 62 64 
server |<7>| 0006 - 
server |<7>| RB: Have 5 bytes into buffer. Adding 96 bytes.
server |<7>| RB: Requested 101 bytes
server |<4>| REC[43618]: Decrypted Packet[0] Handshake(22) with length: 16
server |<6>| BUF[HSK]: Inserted 16 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: FINISHED was received [16 bytes]
server |<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 52 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 12 bytes of Data
server |<3>| REC[43618]: Sent ChangeCipherSpec
server |<4>| REC[43618]: Sending Packet[5] Change Cipher Spec(20) with length: 1
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 6 bytes to 5.
server |<7>| WRITE: wrote 6 bytes to 5. Left 0 bytes. Total 6 bytes.
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 14 03 02 00 01 01 
server |<4>| REC[43618]: Sent Packet[6] Change Cipher Spec(20) with length: 6
server |<3>| HSK[43618]: Cipher Suitclient |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[5] Change Cipher Spec(20) with length: 1
server |<6>| BUF[HSK]: Peeked 16 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
client |<7>| READ: Got 1 bytes from 5
client |<7>| READ: read 1 bytes from 5
client |<7>| 0000 - 01 
client |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
client |<7>| RB: Requested 6 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: ChangeCipherSpec Packet was received
client |<3>| HSK[43df0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Initializing internal [read] cipher sessions
server |<3>| HSK[43618]: FINISHED was send [16 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[0] Handshake(22) with length: 16
server |<7>| WRITE: Will write 245 bytes to 5.
server |<7>| WRITE: wrote 245 bytes to 5. Left 0 bytes. Total 245 bytes.
server |<7>| 0000 - 16 03 02 00 f0 49 99 f6 d7 21 b0 e2 f5 13 b4 62 
server |<7>| 0001 - ac af 25 02 30 64 0e 4e b0 14 23 53 b1 40 e4 a5 
server |<7>| 0002 - 49 c8 db 1b 5e f8 52 30 6c f4 14 0d 67 b6 b5 f7 
server |<7>| 0003 - ee 2d d1 cf a3 ce 64 0f 68 e7 35 de c1 bf 49 62 
server |<7>| 0004 - 02 c7 20 81 5c 92 f8 f2 05 28 a6 fa 13 95 d8 b6 
server |<7>| 0005 - 2e d3 70 41 2c 1b 0f 52 0c 14 84 69 7a 27 a5 46 
server |<7>| 0006 - 06 3b e4 db 5c e4 d9 38 1d 35 8c fd e1 da 04 66 
server |<7>| 0007 - cf 36 f9 7a 21 35 5e 29 73 80 c2 c1 8b 78 01 c8 
server |<7>| 0008 - ff d5 f4 bf 8e 54 a4 0c 4e fb 9a aa 88 33 27 d0 
server |<7>| 0009 - 06 81 f0 0d 53 24 3a 98 64 1c 86 0e 3e 29 cf 50 
server |<7>| 000a - 7c 6d 50 5b f0 a8 3f 4e bc 98 03 6d 53 c6 e5 0a 
server |<7>| 000b - 3f b4 c8 3e 51 f6 f6 2d c3 6c 6f 1b ac 1f 36 15 
server |<7>| 000c - 70 79 6d 3a 79 1e 4f 78 e5 8f 12 f9 0a 82 e3 54 
server |<7>| 000d - d9 a9 8d e4 09 81 5b 79 a5 e5 4f 79 63 fd 30 4b 
server |<7>| 000e - 5a fe 85 e6 31 88 01 76 a9 7b 45 6b 42 c1 98 1c 
server |<7>| 000f - ca 53 c4 54 19 
server |<4>| REC[43618]: Sent Packet[1] Handshake(22) with length: 245
server |<6>| BUF[HSK]: Cleared Data from buffer
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 00 f0 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[0] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[0] Handshake(22) with length: 240
client |<7>| READ: Got 240 bytes from 5
client |<7>| READ: read 240 bytes from 5
client |<7>| 0000 - 49 99 f6 d7 21 b0 e2 f5 13 b4 62 ac af 25 02 30 
client |<7>| 0001 - 64 0e 4e b0 14 23 53 b1 40 e4 a5 49 c8 db 1b 5e 
client |<7>| 0002 - f8 52 30 6c f4 14 0d 67 b6 b5 f7 ee 2d d1 cf a3 
client |<7>| 0003 - ce 64 0f 68 e7 35 de c1 bf 49 62 02 c7 20 81 5c 
client |<7>| 0004 - 92 f8 f2 05 28 a6 fa 13 95 d8 b6 2e d3 70 41 2c 
client |<7>| 0005 - 1b 0f 52 0c 14 84 69 7a 27 a5 46 06 3b e4 db 5c 
client |<7>| 0006 - e4 d9 38 1d 35 8c fd e1 da 04 66 cf 36 f9 7a 21 
client |<7>| 0007 - 35 5e 29 73 80 c2 c1 8b 78 01 c8 ff d5 f4 bf 8e 
client |<7>| 0008 - 54 a4 0c 4e fb 9a aa 88 33 27 d0 06 81 f0 0d 53 
client |<7>| 0009 - 24 3a 98 64 1c 86 0e 3e 29 cf 50 7c 6d 50 5b f0 
client |<7>| 000a - a8 3f 4e bc 98 03 6d 53 c6 e5 0a 3f b4 c8 3e 51 
client |<7>| 000b - f6 f6 2d c3 6c 6f 1b ac 1f 36 15 70 79 6d 3a 79 
client |<7>| 000c - 1e 4f 78 e5 8f 12 f9 0a 82 e3 54 d9 a9 8d e4 09 
client |<7>| 000d - 81 5b 79 a5 e5 4f 79 63 fd 30 4b 5a fe 85 e6 31 
client |<7>| 000e - 88 01 76 a9 7b 45 6b 42 c1 98 1c ca 53 c4 54 19 
client |<7>| 000f - 
client |<7>| RB: Have 5 bytes into buffer. Adding 240 bytes.
client |<7>| RB: Requested 245 bytes
client |<4>| REC[43df0]: Decrypted Packet[0] Handshake(22) with length: 16
client |<6>| BUF[HSK]: Inserted 16 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: FINISHED was received [16 bytes]
client |<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 12 bytes of Data
client |<6>| BUF[HSK]: Cleared Data from buffer
client |<4>| REC[43df0]: Sending Packet[1] Application Data(23) with length: 9
client |<7>| WRITE: Will write 69 bytes to 5.
client |<7>| WRITE: wrote 69 bytes to 5. Left 0 bytes. Total 69 bytes.
client |<7>| 0000 - 17 03 02 00 40 50 f6 16 47 f0 29 2a ce ad 9f 14 
client |<7>| 0001 - 8e de d7 46 d1 43 8f 88 b4 ca b8 88 80 4b 33 28 
client |<7>| 0002 - 30 cc 78 ca e4 a5 c8 19 0d 9e 0c 7f 8d 97 51 02 
client |<7>| 0003 - a5 21 2f 61 4f 86 3d d6 e9 23 9f 51 70 3b 4b 66 
client |<7>| 0004 - 57 b3 11 6e ac 
client |<4>| REC[43df0]: Sent Packet[2] Application Data(23) with length: 69
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 17 03 02 00 40 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[1] Application Data(23) with length: 1024
server |<4>| REC[43618]: Received Packet[1] Application Data(23) with length: 64
server |<7>| READ: Got 63 bytes from 5
server |<7>| READ: read 63 bytes from 5
server |<7>| 0000 - 50 f6 16 47 f0 29 2a ce ad 9f 14 8e de d7 46 d1 
server |<7>| 0001 - 43 8f 88 b4 ca b8 88 80 4b 33 28 30 cc 78 ca e4 
server |<7>| 0002 - a5 c8 19 0d 9e 0c 7f 8d 97 51 02 a5 21 2f 61 4f 
server |<7>| 0003 - 86 3d d6 e9 23 9f 51 70 3b 4b 66 57 b3 11 6e 
server |<7>| RB: Have 5 bytes into buffer. Adding 63 bytes.
server |<7>| RB: Requested 69 bytes
server |<7>| READ: Got 1 bytes from 5
server |<7>| READ: read 1 bytes from 5
server |<7>| 0000 - ac 
server |<7>| RB-PEEK: Read 1 bytes in PEEK MODE.
server |<7>| RB-PEEK: Have 68 bytes into buffer. Adding 1 bytes.
RB: Requested 69 bytes
server |<4>| REC[43618]: Decrypted Packet[1] Application Data(23) with length: 9
server |<6>| BUF[REC]: Inserted 9 bytes of Data(23)
server |<6>| BUFFER[REC][AD]: Read 9 bytes of Data(23)
server |<7>| READ: Got 1 bytes from 5
server |<7>| READ: read 1 bytes from 5
server |<7>| 0000 - ac 
server |<4>| REC[43618]: Sending Packet[1] Application Data(23) with length: 9
server |<7>| WRITE: Will write 213 bytes to 5.
server |<7>| WRITE: wrote 213 bytes to 5. Left 0 bytes. Total 213 bytes.
server |<7>| 0000 - 17 03 02 00 d0 d2 10 a8 fc 19 17 f6 1d 76 c4 91 
server |<7>| 0001 - 6e 9f fb 94 21 16 25 ba 29 16 a0 ec 4d 04 5e cf 
server |<7>| 0002 - 44 03 98 d7 9e 10 25 b9 b7 47 ee 24 ac e7 0e 9a 
server |<7>| 0003 - 84 97 c0 a0 48 09 aa f3 a0 a2 58 b7 51 c1 a1 ec 
server |<7>| 0004 - 4a 26 d0 04 ba da 17 4d 7c b9 8e 91 a9 fb e1 b4 
server |<7>| 0005 - 93 01 ed a0 42 f7 df 5c c8 ed 20 24 cb 53 d8 d2 
server |<7>| 0006 - ce 3a f2 f2 3c 36 0e 75 79 df 17 e5 6d 18 c8 81 
server |<7>| 0007 - 91 c7 66 b1 98 35 a1 bd 7a 26 b9 fa a2 0e 97 40 
server |<7>| 0008 - df 1a 7a aa c2 3a 34 b6 75 80 fa 9d 99 7b 89 e8 
server |<7>| 0009 - 08 d6 12 a8 6a 19 89 64 17 59 ee be 43 f1 72 49 
server |<7>| 000a - 4a 10 1f 41 43 d3 67 fe 32 52 e2 96 3a d6 f6 17 
server |<7>| 000b - ea 50 91 3e 93 a0 df 46 42 de ef d2 75 8b b9 c5 
server |<7>| 000c - 2d bf 8c 3f 54 dc 41 c3 79 57 dc aa f0 65 80 4f 
server |<7>| 000d - 0c 7f dd 98 44 
server |<4>| REC[43618]: Sent Packet[2] Application Data(23) with length: 213
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 17 03 02 00 d0 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[1] Application Data(23) with length: 1024
client |<4>| REC[43df0]: Received Packet[1] Application Data(23) with length: 208
client |<7>| READ: Got 207 bytes from 5
client |<7>| READ: read 207 bytes from 5
client |<7>| 0000 - d2 10 a8 fc 19 17 f6 1d 76 c4 91 6e 9f fb 94 21 
client |<7>| 0001 - 16 25 ba 29 16 a0 ec 4d 04 5e cf 44 03 98 d7 9e 
client |<7>| 0002 - 10 25 b9 b7 47 ee 24 ac e7 0e 9a 84 97 c0 a0 48 
client |<7>| 0003 - 09 aa f3 a0 a2 58 b7 51 c1 a1 ec 4a 26 d0 04 ba 
client |<7>| 0004 - da 17 4d 7c b9 8e 91 a9 fb e1 b4 93 01 ed a0 42 
client |<7>| 0005 - f7 df 5c c8 ed 20 24 cb 53 d8 d2 ce 3a f2 f2 3c 
client |<7>| 0006 - 36 0e 75 79 df 17 e5 6d 18 c8 81 91 c7 66 b1 98 
client |<7>| 0007 - 35 a1 bd 7a 26 b9 fa a2 0e 97 40 df 1a 7a aa c2 
client |<7>| 0008 - 3a 34 b6 75 80 fa 9d 99 7b 89 e8 08 d6 12 a8 6a 
client |<7>| 0009 - 19 89 64 17 59 ee be 43 f1 72 49 4a 10 1f 41 43 
client |<7>| 000a - d3 67 fe 32 52 e2 96 3a d6 f6 17 ea 50 91 3e 93 
client |<7>| 000b - a0 df 46 42 de ef d2 75 8b b9 c5 2d bf 8c 3f 54 
client |<7>| 000c - dc 41 c3 79 57 dc aa f0 65 80 4f 0c 7f dd 98 
client |<7>| RB: Have 5 bytes into buffer. Adding 207 bytes.
client |<7>| RB: Requested 213 bytes
client |<7>| READ: Got 1 bytes from 5
client |<7>| READ: read 1 bytes from 5
client |<7>| 0000 - 44 
client |<7>| RB-PEEK: Read 1 bytes in PEEK MODE.
client |<7>| RB-PEEK: Have 212 bytes into buffer. Adding 1 bytes.
RB: Requested 213 bytes
client |<4>| REC[43df0]: Decrypted Packet[1] Application Data(23) with length: 9
client |<6>| BUF[REC]: Inserted 9 bytes of Data(23)
client |<6>| BUFFER[REC][AD]: Read 9 bytes of Data(23)
client |<7>| READ: Got 1 bytes from 5
client |<7>| READ: read 1 bytes from 5
client |<7>| 0000 - 44 
client |<4>| REC: Sending Alert[1|0] - Close notify
client |<4>| REC[43df0]: Sending Packet[2] Alert(21) with length: 2
client |<7>| WRITE: Will write 261 bytes to 5.
client |<7>| WRITE: wrote 261 bytes to 5. Left 0 bytes. Total 261 bytes.
client |<7>| 0000 - 15 03 02 01 00 75 73 e6 2c 5a 2d 82 5d 57 ed 7b 
client |<7>| 0001 - 48 a5 4c 5d 15 50 8c 97 b8 43 c2 53 da bd da e3 
client |<7>| 0002 - 76 8c 4d 37 be f6 af 0f 63 29 a1 f6 11 52 69 40 
client |<7>| 0003 - 0d 7e 7a a1 2f 23 93 5c 5a 94 4a 84 66 a8 e2 bd 
client |<7>| 0004 - 0c da 8d 96 1e 1e 67 52 21 ca e0 b7 6e f8 7a 66 
client |<7>| 0005 - 08 1e 8e 5f de f2 03 d2 f2 c4 ab ae 33 0a 4c 5c 
client |<7>| 0006 - bc 21 76 fd 0d 0d 56 64 32 10 53 b9 6e 0e 90 c7 
client |<7>| 0007 - ae e7 d1 1a 85 3c 6b fc b9 7b c4 91 cb 33 80 6a 
client |<7>| 0008 - cc f7 4a 99 d3 4d cc da 68 d1 02 45 df 2e eb 71 
client |<7>| 0009 - cc e7 3b 43 a4 35 3f 93 12 87 2d 6b 49 f6 37 bf 
client |<7>| 000a - bd 1b dd 9c 94 a7 ee 97 58 da 15 56 47 65 33 84 
client |<7>| 000b - 66 1e d6 b7 32 c9 c8 ea f0 83 7f ca 39 52 51 d7 
client |<7>| 000c - f7 ea 64 08 63 d7 b6 7b d6 a6 6c 62 71 9c 82 40 
client |<7>| 000d - dc 36 33 c4 67 88 0a 64 aa f8 38 ff 03 a6 0e b3 
client |<7>| 000e - 69 ed a7 ba c4 3c 51 85 52 f8 ec d7 af d0 3e 88 
client |<7>| 000f - 9f 1b 0c aa 58 61 f5 53 1f a5 b6 8d 84 5e 65 b5 
client |<7>| 0010 - c7 63 cb 08 e8 
client |<4>| REC[43df0]: Sent Packet[3] Alert(21) with length: 261
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 15 03 02 01 00 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[2] Application Data(23) with length: 1024
server |<4>| REC[43618]: Received Packet[2] Alert(21) with length: 256
server |<7>| READ: Got 256 bytes from 5
server |<7>| READ: read 256 bytes from 5
server |<7>| 0000 - 75 73 e6 2c 5a 2d 82 5d 57 ed 7b 48 a5 4c 5d 15 
server |<7>| 0001 - 50 8c 97 b8 43 c2 53 da bd da e3 76 8c 4d 37 be 
server |<7>| 0002 - f6 af 0f 63 29 a1 f6 11 52 69 40 0d 7e 7a a1 2f 
server |<7>| 0003 - 23 93 5c 5a 94 4a 84 66 a8 e2 bd 0c da 8d 96 1e 
server |<7>| 0004 - 1e 67 52 21 ca e0 b7 6e f8 7a 66 08 1e 8e 5f de 
server |<7>| 0005 - f2 03 d2 f2 c4 ab ae 33 0a 4c 5c bc 21 76 fd 0d 
server |<7>| 0006 - 0d 56 64 32 10 53 b9 6e 0e 90 c7 ae e7 d1 1a 85 
server |<7>| 0007 - 3c 6b fc b9 7b c4 91 cb 33 80 6a cc f7 4a 99 d3 
server |<7>| 0008 - 4d cc da 68 d1 02 45 df 2e eb 71 cc e7 3b 43 a4 
server |<7>| 0009 - 35 3f 93 12 87 2d 6b 49 f6 37 bf bd 1b dd 9c 94 
server |<7>| 000a - a7 ee 97 58 da 15 56 47 65 33 84 66 1e d6 b7 32 
server |<7>| 000b - c9 c8 ea f0 83 7f ca 39 52 51 d7 f7 ea 64 08 63 
server |<7>| 000c - d7 b6 7b d6 a6 6c 62 71 9c 82 40 dc 36 33 c4 67 
server |<7>| 000d - 88 0a 64 aa f8 38 ff 03 a6 0e b3 69 ed a7 ba c4 
server |<7>| 000e - 3c 51 85 52 f8 ec d7 af d0 3e 88 9f 1b 0c aa 58 
server |<7>| 000f - 61 f5 53 1f a5 b6 8d 84 5e 65 b5 c7 63 cb 08 e8 
server |<7>| 0010 - 
server |<7>| RB: Have 5 bytes into buffer. Adding 256 bytes.
server |<7>| RB: Requested 261 bytes
server |<4>| REC[43618]: Decrypted Packet[2] Alert(21) with length: 2
server |<4>| REC[43618]: Alert[1|0] - Close notify - was received
server |<4>| REC: Sending Alert[1|0] - Close notify
server |<4>| REC[43618]: Sending Packet[2] Alert(21) with length: 2
server |<7>| WRITE: Will write 101 bytes to 5.
server |<7>| WRITE: wrote 101 bytes to 5. Left 0 bytes. Total 101 bytes.
server |<7>| 0000 - 15 03 02 00 60 e7 da bf 5f fe 1c 6a 1e b4 3a 36 
server |<7>| 0001 - 3c b1 1a db 5c c1 81 22 41 33 20 af 55 7a f6 33 
server |<7>| 0002 - 9f 81 b5 16 e1 a0 03 c5 22 77 df a5 51 cf cf df 
server |<7>| 0003 - 35 3f 77 0e ac 0d 7b ec 42 8e da 7c d1 ab c0 bf 
server |<7>| 0004 - 08 ae 0d 52 19 73 2a 1e 0e a7 bf 0d aa da 98 59 
server |<7>| 0005 - 89 4c 0b 3d b9 39 f7 72 d8 d4 08 91 5e 8f 5d 3c 
server |<7>| 0006 - 66 7f fb 14 0f 
server |<4>| REC[43618]: Sent Packet[3] Alert(21) with length: 101
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 15 03 02 00 60 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[2] Alert(21) with length: 0
client |<4>| REC[43df0]: Received Packet[2] Alert(21) with length: 96
client |<7>| READ: Got 96 bytes from 5
client |<7>| READ: read 96 bytes from 5
client |<7>| 0000 - e7 da bf 5f fe 1c 6a 1e b4 3a 36 3c b1 1a db 5c 
client |<7>| 0001 - c1 81 22 41 33 20 af 55 7a f6 33 9f 81 b5 16 e1 
client |<7>| 0002 - a0 03 c5 22 77 df a5 51 cf cf df 35 3f 77 0e ac 
client |<7>| 0003 - 0d 7b ec 42 8e da 7c d1 ab c0 bf 08 ae 0d 52 19 
client |<7>| 0004 - 73 2a 1e 0e a7 bf 0d aa da 98 59 89 4c 0b 3d b9 
client |<7>| 0005 - 39 f7 72 d8 d4 08 91 5e 8f 5d 3c 66 7f fb 14 0f 
client |<7>| 0006 - 
client |<7>| RB: Have 5 bytes into buffer. Adding 96 bytes.
client |<7>| RB: Requested 101 bytes
client |<4>| REC[43df0]: Decrypted Packet[2] Alert(21) with length: 2
client |<4>| REC[43df0]: Alert[1|0] - Close notify - was received
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
Setting key files...
Connecting...
client: Handshake was completed
client: TLS version is: TLS1.1
- Key Exchange: DHE-RSA

- Ephemeral DH using prime of 1032 bits
- Protocol: TLS1.1
- Certificate Type: OPENPGP
- Compression: NULL
- Cipher: AES-128-CBC
- MAC: SHA1
- Received 9 bytes: Hello TLS
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
server: connection from 127.0.0.1, port 44001
server: Handshake was completed
server: TLS version is: TLS1.1
- Key Exchange: DHE-RSA

- Ephemeral DH using prime of 1032 bits
- Protocol: TLS1.1
- Certificate Type: OPENPGP
- Compression: NULL
- Cipher: AES-128-CBC
- MAC: SHA1
server: Peer has closed the GNUTLS connection
server: finished
PASS: openpgpself
===================
All 19 tests passed

From simon at josefsson.org  Thu Jun  5 15:17:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 05 Jun 2008 15:17:02 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <4846C989.7040906@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed, 04 Jun 2008 19:57:45 +0300")
References: <20080525080428.GB3208@downhill.g.la>
	<4842D055.2020002@gnutls.org> <20080602172252.GB3060@downhill.g.la>
	<4844517A.3030002@gnutls.org> <87y75lanr5.fsf@mocca.josefsson.org>
	<4846C989.7040906@gnutls.org>
Message-ID: <87wsl42f8x.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>> FWIW, this seems to happen on my system as well, a normal x86 debian
>> box.  Does it work on your machine?  There are valgrind errors, see
>> below.
>
>> ==18506== Use of uninitialised value of size 4
>> ==18506==    at 0x4181141: (within /lib/i686/cmov/libc-2.7.so)
>> ==18506==    by 0x4183079: vfprintf (in /lib/i686/cmov/libc-2.7.so)
>> ==18506==    by 0x41A0E9B: vsprintf (in /lib/i686/cmov/libc-2.7.so)
>> ==18506==    by 0x418B24D: sprintf (in /lib/i686/cmov/libc-2.7.so)
>> ==18506==    by 0x40600D6: _gnutls_bin2hex (gnutls_str.c:265)
>> ==18506==    by 0x406E19E: _gnutls_openpgp_privkey_to_gkey (gnutls_openpgp.c:731)
>
> This one looks quite strange. Does the openpgpself fail to your system
> as well? Does it still fail with my latest commit?

Nope, your latest commit fixed the problem for me too.  I've fixed so
that the self tests will now fail 'make check' when the PGP/TLS
handshake fails.

/Simon




From rgerhards at gmail.com  Fri Jun  6 10:08:09 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 6 Jun 2008 10:08:09 +0200
Subject: error during make
Message-ID: <dc67eef70806060108k1a20c3efp32cee349cb4c7e60@mail.gmail.com>

Hi,

I have just started to building GnuTLS and having problems with the
initial steps. I hope this is the right mailing list for that kind of
things, too.

I am working on Fedora 9. I pulled the git archive roughly an hour
ago. I ran ./configure without arguments. During make, I get the
following error:

gcc -std=gnu99 -pipe -g -O2 -Wno-pointer-sign -o ex-serv-psk
ex-serv-psk.o  ./.libs/libexamples.a ../../lib/.libs/libgnutls.so
../../libextra/.libs/libgnutls-extra.so
/home/rger/proj/gnutls/lib/.libs/libgnutls.so -ltasn1 -lz
../../gl/.libs/libgnu.a -lgcrypt -lgpg-error  -Wl,--rpath
-Wl,/home/rger/proj/gnutls/lib/.libs -Wl,--rpath
-Wl,/home/rger/proj/gnutls/libextra/.libs -Wl,--rpath
-Wl,/usr/local/lib
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../includes -I../../includes
-I../../lgl -I../../lgl -I../../gl -I../../gl   -g -O2 -MT ex-cxx.o
-MD -MP -MF .deps/ex-cxx.Tpo -c -o ex-cxx.o ex-cxx.cpp
ex-cxx.cpp: In function 'int main()':
ex-cxx.cpp:71: error: 'strlen' was not declared in this scope
make[4]: *** [ex-cxx.o] Error 1
make[4]: Leaving directory `/home/rger/proj/gnutls/doc/examples'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/rger/proj/gnutls/doc'

Any advise would be appreciated.

Thanks,
Rainer




From simon at josefsson.org  Sat Jun  7 22:11:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 07 Jun 2008 22:11:34 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
Message-ID: <87fxrpxax5.fsf@mocca.josefsson.org>

This the second release candidate for 2.4.0.  Anything that doesn't live
up to the expectations on a stable release should be reported before
this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
or two.

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

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

Alas, the spammers have found our trac site so it is almost useless. :(
Hopefully I can move it to another host soon...  Is anyone interested in
helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!

More ideas are welcome, just create a new ticket.

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

Here is the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.3.13.exe
  http://josefsson.org/gnutls4win/gnutls-2.3.13.zip

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.13-1_all.deb

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.

News in this release:

* Version 2.3.13 (released 2008-06-07)

** libgnutls [OpenPGP]: Make OpenPGP handshakes work again.

** doc/: Add psktool to info index.  Some minor cleanups.

** tests/: Added non-forking TLS handshake test, see tests/mini.c.

** tests/: Added libgcrypt.supp which can be used with valgrind.
The file suppresses the known libgcrypt memory leaks, so they aren't
printed when you run valgrind on the gnutls self-tests.  Use it as
follows: valgrind --suppressions=libgcrypt.supp ./x509self or add
'--suppressions=/home/you/src/gnutls/tests/libgcrypt.supp' to your
~/.valgrindrc file.

** tests/: Reduce amount of debugging output by default.
Use --verbose for each test to get the full output.

** tests/: Fix memory leaks in several self-tests.
None of the self tests should be leaking memory when running valgrind
or similar tools.  (Known exceptions are dhepskself, pskself, and
set_pkcs12_cred, which appear likely to be due to memory leaks in the
library.)

** API and ABI modifications:
No changes since last version.

/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/20080607/cb27bebc/attachment.pgp>

From simon at josefsson.org  Sat Jun  7 22:29:40 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 07 Jun 2008 22:29:40 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <20080604145320.GB21148@manyfish.co.uk> (Joe Orton's message of
	"Wed, 4 Jun 2008 15:53:20 +0100")
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080604104254.GA20298@manyfish.co.uk>
	<87ej7d5mr6.fsf@mocca.josefsson.org>
	<20080604145320.GB21148@manyfish.co.uk>
Message-ID: <87bq2dxa2z.fsf@mocca.josefsson.org>

I propose to avoid bumping the shared library version for 2.4.0, to save
most people a lot of hassles with recompiling packages.  Further, the
release notes will say that we have moved symbols from libgnutls-extra
to libgnutls, and that if anyone encounters a significant problem on
some platform which would be solved by bumping the shared library
version, we acknowledge that we will be forced to release a 2.4.1 with
the ABI version bumped, treating the decision made for 2.4.0 to not bump
the ABI a bug.

This approach isn't the most conservative choice (that would be to bump
the ABI version), but given the feedback I've seen so far, people prefer
to not bump the ABI version.

What do you think?

Thanks to all those who provided feedback,
/Simon




From aspecialj at gmail.com  Sat Jun  7 22:40:19 2008
From: aspecialj at gmail.com (John Brooks)
Date: Sat, 7 Jun 2008 14:40:19 -0600
Subject: Fwd: error during make
In-Reply-To: <dc67eef70806060906p565e0efp4a346d649b350d3d@mail.gmail.com>
References: <dc67eef70806060108k1a20c3efp32cee349cb4c7e60@mail.gmail.com>
	<e646fda30806060840s5ef6db2odebc4dfb6376fbe@mail.gmail.com>
	<dc67eef70806060906p565e0efp4a346d649b350d3d@mail.gmail.com>
Message-ID: <e646fda30806071340h27fda9b0t9b2be360c5ef8251@mail.gmail.com>

Forwarding this to the list because i'm not sure it all got through. The
example doc/examples/ex-cxx.cpp does not directly include the C header
string.h and uses strlen, which can apparently cause a compile error on some
systems (where the C++ headers are not including string.h themselves).
Including string.h directly solved the issue.

- John

---------- Forwarded message ----------
From: Rainer Gerhards <rgerhards at gmail.com>
Date: Fri, Jun 6, 2008 at 10:06 AM
Subject: Re: error during make
To: John Brooks <aspecialj at gmail.com>


Thanks, that solves the issue. I was a bit hesitant to modify the
sources at this stage of my "knowledge".

Rainer

On Fri, Jun 6, 2008 at 5:40 PM, John Brooks <aspecialj at gmail.com> wrote:
> I don't see that example including any C headers, so try adding '#include
> <string.h>' to the top of that file (doc/examples/ex-cxx.cpp) and
compiling
> again. It's possible that your system, unlike the system of whoever wrote
> it, will not define strlen inside those C++ headers that were included.
>
> Let us know if that works
>
>  - John
>
> On Fri, Jun 6, 2008 at 2:08 AM, Rainer Gerhards <rgerhards at gmail.com>
wrote:
>>
>> Hi,
>>
>> I have just started to building GnuTLS and having problems with the
>> initial steps. I hope this is the right mailing list for that kind of
>> things, too.
>>
>> I am working on Fedora 9. I pulled the git archive roughly an hour
>> ago. I ran ./configure without arguments. During make, I get the
>> following error:
>>
>> gcc -std=gnu99 -pipe -g -O2 -Wno-pointer-sign -o ex-serv-psk
>> ex-serv-psk.o  ./.libs/libexamples.a ../../lib/.libs/libgnutls.so
>> ../../libextra/.libs/libgnutls-extra.so
>> /home/rger/proj/gnutls/lib/.libs/libgnutls.so -ltasn1 -lz
>> ../../gl/.libs/libgnu.a -lgcrypt -lgpg-error  -Wl,--rpath
>> -Wl,/home/rger/proj/gnutls/lib/.libs -Wl,--rpath
>> -Wl,/home/rger/proj/gnutls/libextra/.libs -Wl,--rpath
>> -Wl,/usr/local/lib
>> g++ -DHAVE_CONFIG_H -I. -I../..  -I../../includes -I../../includes
>> -I../../lgl -I../../lgl -I../../gl -I../../gl   -g -O2 -MT ex-cxx.o
>> -MD -MP -MF .deps/ex-cxx.Tpo -c -o ex-cxx.o ex-cxx.cpp
>> ex-cxx.cpp: In function 'int main()':
>> ex-cxx.cpp:71: error: 'strlen' was not declared in this scope
>> make[4]: *** [ex-cxx.o] Error 1
>> make[4]: Leaving directory `/home/rger/proj/gnutls/doc/examples'
>> make[3]: *** [all-recursive] Error 1
>> make[3]: Leaving directory `/home/rger/proj/gnutls/doc'
>>
>> Any advise would be appreciated.
>>
>> Thanks,
>> Rainer
>>
>>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
>
>
> --
> - John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080607/6098f004/attachment.htm>

From simon at josefsson.org  Sat Jun  7 22:48:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 07 Jun 2008 22:48:31 +0200
Subject: Fwd: error during make
In-Reply-To: <e646fda30806071340h27fda9b0t9b2be360c5ef8251@mail.gmail.com>
	(John Brooks's message of "Sat, 7 Jun 2008 14:40:19 -0600")
References: <dc67eef70806060108k1a20c3efp32cee349cb4c7e60@mail.gmail.com>
	<e646fda30806060840s5ef6db2odebc4dfb6376fbe@mail.gmail.com>
	<dc67eef70806060906p565e0efp4a346d649b350d3d@mail.gmail.com>
	<e646fda30806071340h27fda9b0t9b2be360c5ef8251@mail.gmail.com>
Message-ID: <877id1x97k.fsf@mocca.josefsson.org>

"John Brooks" <aspecialj at gmail.com> writes:

> Forwarding this to the list because i'm not sure it all got through. The
> example doc/examples/ex-cxx.cpp does not directly include the C header
> string.h and uses strlen, which can apparently cause a compile error on some
> systems (where the C++ headers are not including string.h themselves).
> Including string.h directly solved the issue.

Thanks for forwarding this.  I've added the #include.  Unfortunately, it
didn't go into 2.3.13, but will be in 2.3.14 or 2.4.0.

Thanks,
/Simon




From frank at cyblogic.de  Sun Jun  8 08:11:54 2008
From: frank at cyblogic.de (Frank Mertens)
Date: Sun, 08 Jun 2008 08:11:54 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87fxrpxax5.fsf@mocca.josefsson.org>
References: <87fxrpxax5.fsf@mocca.josefsson.org>
Message-ID: <484B782A.5080701@cyblogic.de>

Simon Josefsson wrote:
> This the second release candidate for 2.4.0.  Anything that doesn't live
> up to the expectations on a stable release should be reported before
> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
> or two.
> 
> The goals for the 2.3.x branch are tracked at:
> 
> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4
> 
> Alas, the spammers have found our trac site so it is almost useless. :(
> Hopefully I can move it to another host soon...  Is anyone interested in
> helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!
> 

What about redmine? My wife told me she would setup a redmine plus
akismet spam filtering for my new project. Would be a honor for
us to also host gnutls. We are using a Xen-based virtual server on
gandi.net.

Frank
--




From nmav at gnutls.org  Sun Jun  8 10:58:30 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jun 2008 11:58:30 +0300
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87fxrpxax5.fsf@mocca.josefsson.org>
References: <87fxrpxax5.fsf@mocca.josefsson.org>
Message-ID: <484B9F36.6090901@gnutls.org>

Simon Josefsson wrote:
> This the second release candidate for 2.4.0.  Anything that doesn't live
> up to the expectations on a stable release should be reported before
> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
> or two.
> 
> The goals for the 2.3.x branch are tracked at:
> 
> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

The last open issue with this release has now been solved in the
repository (issue being the OpenPGP certificate verification).

regards,
Nikos




From mrsam at courier-mta.com  Sun Jun  8 17:11:22 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 08 Jun 2008 11:11:22 -0400
Subject: man page for gnutls_x509_crt_get_extension_info
Message-ID: <cone.1212937882.140784.15248.500@commodore.email-scan.com>

Unlike other _get_() pages, the man page for this function does not 
explicitly state that if oid and sizeof_id are zeroes, sizeof_id gets filled 
in with the size of the buffer that needs to be allocated for the returned 
data.

But, a brief peek at the code does suggest that this is the case. Can this 
be clarified, in the man page?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20080608/225411df/attachment.pgp>

From simon at josefsson.org  Sun Jun  8 22:14:21 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 08 Jun 2008 22:14:21 +0200
Subject: man page for gnutls_x509_crt_get_extension_info
In-Reply-To: <cone.1212937882.140784.15248.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Sun, 08 Jun 2008 11:11:22 -0400")
References: <cone.1212937882.140784.15248.500@commodore.email-scan.com>
Message-ID: <87y75fheg2.fsf@mocca.josefsson.org>

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

> Unlike other _get_() pages, the man page for this function does not
> explicitly state that if oid and sizeof_id are zeroes, sizeof_id gets
> filled in with the size of the buffer that needs to be allocated for
> the returned data.
>
> But, a brief peek at the code does suggest that this is the case. Can
> this be clarified, in the man page?

Thanks for the report, patch pushed:

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

/Simon




From dkg-debian.org at fifthhorseman.net  Sun Jun  8 23:57:16 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 08 Jun 2008 17:57:16 -0400
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <484B9F36.6090901@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun\, 08 Jun 2008 11\:58\:30 +0300")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
Message-ID: <87skvnfv43.fsf@squeak.fifthhorseman.net>

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

On Sun 2008-06-08 04:58:30 -0400, Nikos Mavrogiannopoulos wrote:

> Simon Josefsson wrote:
>> This the second release candidate for 2.4.0.  Anything that doesn't live
>> up to the expectations on a stable release should be reported before
>> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
>> or two.
>> 
>> The goals for the 2.3.x branch are tracked at:
>> 
>> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4
>
> The last open issue with this release has now been solved in the
> repository (issue being the OpenPGP certificate verification).

It's not clear to me if you mean that this should be resolved in
2.3.12, or after 2.3.12, Nikos.  It looks to me like it has *not* been
resolved in 2.3.12 yet.  In particular, it appears to fail open: when
one userid is verified, it treats them all as verified, even User IDs
that have no certifications other than self-signatures.

When i run the tests from
http://trac.gnutls.org/cgi-bin/trac.cgi/attachment/ticket/32/openpgp-certs.tgz
against the 2.3.12 packages in debian experimental, i get the
following output:

[0 dkg at squeak openpgp-certs]$ ./testcerts 
Set static Diffie Hellman parameters, consider --dhparams.
Echo Server ready. Listening to port '12345'.

Failure: Connection to unverified (but present) 'localhost' should have failed!
Exiting via signal 15
Set static Diffie Hellman parameters, consider --dhparams.
Echo Server ready. Listening to port '12345'.

Failure: Connection to unverified IP address should have failed! (error code 0)
Exiting via signal 15
[1 dkg at squeak openpgp-certs]$ 


   --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQIVAwUBSExVwszS7ZTSFznpAQKSHQ/8Do0CLciHXS70M2Qf5eeqJO75iC2+PONP
ZZN77ikf5EvXrFo855hzt8FnlIh28rW+fUEOBaYbQZXAimFZvD+Ro6ERPGPYmoOt
ICuUtmc3t5rcuKT9b9gmnk0QaRyzTN1caCERa5pSTO9xGJKpE/qWjnZ3bSMZ+xAS
Tbx8il6MMB4Vdx8x8qJQkB+x3QnbOI3K4si0AXhpv9VmcuJjL+6YSwtApS394YKe
f0ebrjkVm+3YMjoge5EstW0hY5kCJsElLrfxUQeMtvoaulovQoKH7kZhTxuzMGk2
zQXgX93VMZdOA6tbQkX646dQalyXm2d/NHWunBSgocy9yTNKu7inbrDFG0vFQ0j6
B/3nOmLeLjMobAQspq6va8benezeSEIeSmVrcOli8wSnERToUDTydz9FNBnEkRic
vVXamMjH03S/HtmJn1HRAAxiQtAiyu+G68LVr7cCi7Ctanu463e7DajGrts8lk4k
Wr2hZ7IQ++cj/5GJaT19fGeFaBSwrae7rq25COeX4+UOfjJwgbMGtmqkTQv/1XzM
EkkCKjiZ0lwFELmibLni+wg2SpEQdNd8f2WQ/yV4Aj4nqY5e8LojNF2g2Ra5MtPY
ehUbPUjRyFsOO0Y+s4gIBo/EhaTFhOqv/sOg8QDenYwAvG57/fCvObGORYcULIHE
w1CHGL0ogbU=
=Nzgk
-----END PGP SIGNATURE-----




From simon at josefsson.org  Mon Jun  9 08:47:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 09 Jun 2008 08:47:38 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87skvnfv43.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Sun, 08 Jun 2008 17:57:16 -0400")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
Message-ID: <87od6bdrzp.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Sun 2008-06-08 04:58:30 -0400, Nikos Mavrogiannopoulos wrote:
>
>> Simon Josefsson wrote:
>>> This the second release candidate for 2.4.0.  Anything that doesn't live
>>> up to the expectations on a stable release should be reported before
>>> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
>>> or two.
>>> 
>>> The goals for the 2.3.x branch are tracked at:
>>> 
>>> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4
>>
>> The last open issue with this release has now been solved in the
>> repository (issue being the OpenPGP certificate verification).
>
> It's not clear to me if you mean that this should be resolved in
> 2.3.12, or after 2.3.12, Nikos.  It looks to me like it has *not* been
> resolved in 2.3.12 yet.  In particular, it appears to fail open: when
> one userid is verified, it treats them all as verified, even User IDs
> that have no certifications other than self-signatures.

Actually, it should only be fixed after 2.3.13, but it seems the daily
builds for trunk has stopped working some time ago -- I'll try to fix
that.

> When i run the tests from
> http://trac.gnutls.org/cgi-bin/trac.cgi/attachment/ticket/32/openpgp-certs.tgz
> against the 2.3.12 packages in debian experimental, i get the
> following output:
>
> [0 dkg at squeak openpgp-certs]$ ./testcerts 
> Set static Diffie Hellman parameters, consider --dhparams.
> Echo Server ready. Listening to port '12345'.
>
> Failure: Connection to unverified (but present) 'localhost' should have failed!
> Exiting via signal 15
> Set static Diffie Hellman parameters, consider --dhparams.
> Echo Server ready. Listening to port '12345'.
>
> Failure: Connection to unverified IP address should have failed! (error code 0)
> Exiting via signal 15
> [1 dkg at squeak openpgp-certs]$ 

I'll do a 2.3.14 release so that you can confirm that this has been
fixed.

Thanks,
Simon




From simon at josefsson.org  Mon Jun  9 08:50:33 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 09 Jun 2008 08:50:33 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <484B782A.5080701@cyblogic.de> (Frank Mertens's message of "Sun, 
	08 Jun 2008 08:11:54 +0200")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B782A.5080701@cyblogic.de>
Message-ID: <87k5gzdruu.fsf@mocca.josefsson.org>

Frank Mertens <frank at cyblogic.de> writes:

> Simon Josefsson wrote:
>> This the second release candidate for 2.4.0.  Anything that doesn't live
>> up to the expectations on a stable release should be reported before
>> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
>> or two.
>>
>> The goals for the 2.3.x branch are tracked at:
>>
>> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4
>>
>> Alas, the spammers have found our trac site so it is almost useless. :(
>> Hopefully I can move it to another host soon...  Is anyone interested in
>> helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!
>>
>
> What about redmine? My wife told me she would setup a redmine plus
> akismet spam filtering for my new project. Would be a honor for
> us to also host gnutls. We are using a Xen-based virtual server on
> gandi.net.

Thanks for offering!  I have not used redmine...  I'll take a look.  If
others have thoughts about it, that would be appreciated as well.

I think what we need is a wiki and bug/issue-tracking with good
roadmap-tracking of each bug/issue.

Alternatively, I'll check prices for VPS's too, possibly I can donate
some funding to the gnutls project to keep a small VPS running.

/Simon




From n.mavrogiannopoulos at gmail.com  Mon Jun  9 14:01:17 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 9 Jun 2008 15:01:17 +0300
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87skvnfv43.fsf@squeak.fifthhorseman.net>
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
Message-ID: <c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>

On Mon, Jun 9, 2008 at 12:57 AM, Daniel Kahn Gillmor
<dkg-debian.org at fifthhorseman.net> wrote:

> It's not clear to me if you mean that this should be resolved in
> 2.3.12, or after 2.3.12, Nikos.  It looks to me like it has *not* been
> resolved in 2.3.12 yet.  In particular, it appears to fail open: when
> one userid is verified, it treats them all as verified, even User IDs
> that have no certifications other than self-signatures.

> When i run the tests from
> http://trac.gnutls.org/cgi-bin/trac.cgi/attachment/ticket/32/openpgp-certs.tgz
> against the 2.3.12 packages in debian experimental, i get the
> following output:

Hello Daniel!
 I was talking about a recent commit in the git repository. I've also
modified your tests to check the gnutls behaviour (as it is now both
of your tests should fail). The new behaviour is to consider not
verified all openpgp keys that have at least one unsigned by a trusted
party user id.

regards,
Nikos




From dkg at fifthhorseman.net  Mon Jun  9 17:59:14 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 09 Jun 2008 11:59:14 -0400
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon\,
	9 Jun 2008 15\:01\:17 +0300")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
	<c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
Message-ID: <87r6b68ur1.fsf@squeak.fifthhorseman.net>

On Mon 2008-06-09 08:01:17 -0400, Nikos Mavrogiannopoulos wrote:

>  I was talking about a recent commit in the git repository. I've
> also modified your tests to check the gnutls behaviour (as it is now
> both of your tests should fail). The new behaviour is to consider
> not verified all openpgp keys that have at least one unsigned by a
> trusted party user id.

Hi Nikos--

Thanks for clarifying.  The failure you describe sounds like the right
thing until we can fix up the API to do more nuanced hostname
checking.

Sorry i haven't been able to help out as much as i wanted to.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080609/27a87a47/attachment.pgp>

From simon at josefsson.org  Tue Jun 10 12:55:44 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 10 Jun 2008 12:55:44 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 9 Jun 2008 15:01:17
	+0300")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
	<c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
Message-ID: <87abhto8y7.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Mon, Jun 9, 2008 at 12:57 AM, Daniel Kahn Gillmor
> <dkg-debian.org at fifthhorseman.net> wrote:
>
>> It's not clear to me if you mean that this should be resolved in
>> 2.3.12, or after 2.3.12, Nikos.  It looks to me like it has *not* been
>> resolved in 2.3.12 yet.  In particular, it appears to fail open: when
>> one userid is verified, it treats them all as verified, even User IDs
>> that have no certifications other than self-signatures.
>
>> When i run the tests from
>> http://trac.gnutls.org/cgi-bin/trac.cgi/attachment/ticket/32/openpgp-certs.tgz
>> against the 2.3.12 packages in debian experimental, i get the
>> following output:
>
> Hello Daniel!
>  I was talking about a recent commit in the git repository. I've also
> modified your tests to check the gnutls behaviour (as it is now both
> of your tests should fail). The new behaviour is to consider not
> verified all openpgp keys that have at least one unsigned by a trusted
> party user id.

Nikos, the self-test doesn't seem to work, see below.

/Simon

make[1]: Entering directory `/home/jas/src/gnutls/tests/openpgp-certs'
+ srcdir=.
+ SERV='../../src/gnutls-serv -q'
+ CLI=../../src/gnutls-cli
+ unset RETCODE
+ echo 'Checking OpenPGP certificate verification'
Checking OpenPGP certificate verification
+ ../../src/gnutls-serv -q -p 5556 --pgpcertfile ./srv-public-127.0.0.1-signed.gpg --pgpkeyfile ./srv-secret.gpg
+ sleep 2
+ ../../src/gnutls-cli -p 5556 127.0.0.2 --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ ../../src/gnutls-cli -p 5556 localhost --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ kill %1
+ wait
+ ../../src/gnutls-serv -q -p 5556 --pgpcertfile ./srv-public-localhost-signed.gpg --pgpkeyfile ./srv-secret.gpg
+ sleep 2
+ echo
+ ../../src/gnutls-cli -p 5556 127.0.0.1 --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ ../../src/gnutls-cli -p 5556 127.0.0.2 --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ kill %1
+ wait
+ ../../src/gnutls-serv -q -p 5556 --pgpcertfile ./srv-public-all-signed.gpg --pgpkeyfile ./srv-secret.gpg
+ sleep 2
+ echo
+ ../../src/gnutls-cli -p 5556 127.0.0.1 --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ fail 'Connection to signed PGP certificate should have succeeded! (error code 1)' 1
+ echo 'Failure: Connection to signed PGP certificate should have succeeded! (error code 1)'
Failure: Connection to signed PGP certificate should have succeeded! (error code 1)
+ RETCODE=1
+ ../../src/gnutls-cli -p 5556 127.0.0.2 --pgpkeyring ./ca-public.gpg
*** Fatal error: A TLS fatal alert has been received.
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
+ kill %1
+ wait
+ exit 1
FAIL: testcerts
===================================
1 of 1 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/home/jas/src/gnutls/tests/openpgp-certs'
make: *** [check-am] Error 2
jas at mocca:~/src/gnutls/tests/openpgp-certs$ 





From n.mavrogiannopoulos at gmail.com  Tue Jun 10 15:20:30 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 10 Jun 2008 16:20:30 +0300
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87abhto8y7.fsf@mocca.josefsson.org>
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
	<c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
	<87abhto8y7.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0806100620q1078d21ck5c63d4365011d242@mail.gmail.com>

On Tue, Jun 10, 2008 at 1:55 PM, Simon Josefsson <simon at josefsson.org> wrote:
> Nikos, the self-test doesn't seem to work, see below.

Could you increase the verbosity? It works for me and I cannot reproduce it.


regards,
Nikos




From simon at josefsson.org  Tue Jun 10 16:06:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 10 Jun 2008 16:06:02 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <c331d99a0806100620q1078d21ck5c63d4365011d242@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 10 Jun 2008 16:20:30
	+0300")
References: <87fxrpxax5.fsf@mocca.josefsson.org> <484B9F36.6090901@gnutls.org>
	<87skvnfv43.fsf@squeak.fifthhorseman.net>
	<c331d99a0806090501oe465020if1c064ef77727f82@mail.gmail.com>
	<87abhto8y7.fsf@mocca.josefsson.org>
	<c331d99a0806100620q1078d21ck5c63d4365011d242@mail.gmail.com>
Message-ID: <87prqpmlkl.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Tue, Jun 10, 2008 at 1:55 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> Nikos, the self-test doesn't seem to work, see below.
>
> Could you increase the verbosity? It works for me and I cannot reproduce it.

Heh...

bind() failed: Address already in use

I had a gnutls-serv running in background that I had forgotten about.

I changed so that the script uses port 5557 instead, which might make
accidental failures like this less likely.

/Simon




From simon at josefsson.org  Wed Jun 11 00:23:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Jun 2008 00:23:01 +0200
Subject: GnuTLS 2.3.14 - third release candidate for 2.4.0
Message-ID: <87r6b5j5fe.fsf@mocca.josefsson.org>

This the third release candidate for 2.4.0.  Anything that doesn't live
up to the expectations on a stable release should be reported before
this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
or two.  I'm going away a few days, but will be back next Monday.  If
there has been no reports then, perhaps I can release 2.4.0 early next
week....

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

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

Alas, the spammers have found our trac site so it is almost useless. :(
Hopefully I can move it to another host soon...  Is anyone interested in
helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!

More ideas are welcome, just create a new ticket.

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

No Windows binaries for this release because the openpgp-certs self-test
failed under Wine, I'll investigate and fix before 2.4.0.

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.

News in this release:

* Version 2.3.14 (released 2008-06-11)

** libgnutls [OpenPGP]: Changed OpenPGP verification behaviour.
An OpenPGP certificate is now only considered verified if all the user
IDs are verified.

** Examples: Make C++ example compile.
Earlier it may have failed with an unresolved reference to strlen.

** Documentation: Doc fix for gnutls_x509_crt_get_extension_oid.
Reported by Sam Varshavchik <mrsam at courier-mta.com>.

** API and ABI modifications:
No changes since last version.

/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/20080611/ac0bd4a4/attachment.pgp>

From simon at josefsson.org  Wed Jun 11 10:41:11 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Jun 2008 10:41:11 +0200
Subject: openpgp-certs failure under wine
In-Reply-To: <87r6b5j5fe.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 11 Jun 2008 00:23:01 +0200")
References: <87r6b5j5fe.fsf@mocca.josefsson.org>
Message-ID: <87mylsict4.fsf@mocca.josefsson.org>

The gnutls-serv started from openpgp-certs doesn't seem to start under
Wine, here is the output:

jas at mocca:~/gnutls4win/build/gnutls-2.3.14/tests/openpgp-certs$ ../../src/gnutls-serv -q -p 5557 --pgpcertfile ../../../../src/gnutls-2.3.14/tests/openpgp-certs/srv-public-127.0.0.1-signed.gpg --pgpkeyfile ../../../../src/gnutls-2.3.14/tests/openpgp-certs/srv-secret.gpg -d 4711
NOTE: you should run 'diskperf -y' to enable the disk statistics
DBG: rndw32: get performance data problem: ec=2
Set static Diffie Hellman parameters, consider --dhparams.
|<2>| ASSERT: ../../../../src/gnutls-2.3.14/lib/openpgp/privkey.c:125
|<2>| ASSERT: ../../../src/gnutls-2.3.14/lib/gnutls_openpgp.c:379
|<2>| ASSERT: ../../../src/gnutls-2.3.14/lib/gnutls_openpgp.c:500
Error[-59] while reading the OpenPGP key pair ('../../../../src/gnutls-2.3.14/tests/openpgp-certs/srv-public-127.0.0.1-signed.gpg', '../../../../src/gnutls-2.3.14/tests/openpgp-certs/srv-secret.gpg')
Error: GnuTLS internal error.
Echo Server ready. Listening to port '5557'.

select(): Success
jas at mocca:~/gnutls4win/build/gnutls-2.3.14/tests/openpgp-certs$ 

I can reproduce the openpgp key import error using certtool and the
particular OpenPGP file:

jas at mocca:~/gnutls4win/build/gnutls-2.3.14/tests/openpgp-certs$ ~/gnutls4win/build/gnutls-2.3.14/src/certtool --pgp-certificate-info --infile ../../../../src/gnutls-2.3.14/tests/openpgp-certs/srv-public-127.0.0.1-signed.gpg -d 4711
NOTE: you should run 'diskperf -y' to enable the disk statistics
DBG: rndw32: get performance data problem: ec=2
|<2>| ASSERT: ../../../../src/gnutls-2.3.14/lib/openpgp/pgp.c:124
certtool.exe: Import error: GnuTLS internal error.
jas at mocca:~/gnutls4win/build/gnutls-2.3.14/tests/openpgp-certs$ 

Tracing it further, it seems it OpenCDK is returning EOF when parsing
the OpenPGP key, I'm not sure why.

Nikos, can you reproduce this?  You'll need to install mingw32, wine,
binfmt-support and run ./configure --host=i586-mingw32msvc
--build=i686-pc-linux-gnu if you are using debian.

I'm leaving now, but will look into this next week unless you or someone
else has had time to debug it.

/Simon




From n.mavrogiannopoulos at gmail.com  Thu Jun 12 12:21:17 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 12 Jun 2008 13:21:17 +0300
Subject: openpgp-certs failure under wine
In-Reply-To: <87mylsict4.fsf@mocca.josefsson.org>
References: <87r6b5j5fe.fsf@mocca.josefsson.org>
	<87mylsict4.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0806120321q23e9330foe1d1fd70b60f4929@mail.gmail.com>

> Tracing it further, it seems it OpenCDK is returning EOF when parsing
> the OpenPGP key, I'm not sure why.
>
> Nikos, can you reproduce this?  You'll need to install mingw32, wine,
> binfmt-support and run ./configure --host=i586-mingw32msvc
> --build=i686-pc-linux-gnu if you are using debian.

Unfortunately not. gnutls couldn't compile with the setup (something
about missing libgcrypt etc).

> I'm leaving now, but will look into this next week unless you or someone
> else has had time to debug it.

I'm also leaving for holidays today so I'll be unable to work on this soon.

regards,
Nikos




From dkg at fifthhorseman.net  Thu Jun 12 16:46:59 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 12 Jun 2008 10:46:59 -0400
Subject: GnuTLS 2.3.14 - third release candidate for 2.4.0
In-Reply-To: <87r6b5j5fe.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 11 Jun 2008 00\:23\:01 +0200")
References: <87r6b5j5fe.fsf@mocca.josefsson.org>
Message-ID: <87skvipv6k.fsf@squeak.fifthhorseman.net>

On Tue 2008-06-10 18:23:01 -0400, Simon Josefsson wrote:

> * Version 2.3.14 (released 2008-06-11)
>
> ** libgnutls [OpenPGP]: Changed OpenPGP verification behaviour.
> An OpenPGP certificate is now only considered verified if all the user
> IDs are verified.

I've tested this change against Andreas Metzler's debian packaging of
2.3.14, and it looks correct.  A single unverifiable User ID on the
certificate causes verification failure.  This "fail closed" behavior
is significantly better than the earlier "fail open" behavior.
Thanks!

Hopefully for gnutls 2.6 we can cook up more nuanced OpenPGP
certificate verification, where irrelevant unverified UserIDs don't
cause a failure.

Thanks for all the work on this,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080612/d80a50af/attachment.pgp>

From frank.mertens at cyblogic.com  Fri Jun 13 02:20:32 2008
From: frank.mertens at cyblogic.com (Frank Mertens)
Date: Fri, 13 Jun 2008 02:20:32 +0200
Subject: GnuTLS 2.3.12 - second release candidate for 2.4.0
In-Reply-To: <87k5gzdruu.fsf@mocca.josefsson.org>
References: <87fxrpxax5.fsf@mocca.josefsson.org>	<484B782A.5080701@cyblogic.de>
	<87k5gzdruu.fsf@mocca.josefsson.org>
Message-ID: <4851BD50.7020105@cyblogic.com>

Simon Josefsson wrote:
> Frank Mertens <frank at cyblogic.de> writes:
> 
>> Simon Josefsson wrote:
>>> This the second release candidate for 2.4.0.  Anything that doesn't live
>>> up to the expectations on a stable release should be reported before
>>> this turns into the real 2.4.0.  We hope to release 2.4.0 within a week
>>> or two.
>>>
>>> The goals for the 2.3.x branch are tracked at:
>>>
>>> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4
>>>
>>> Alas, the spammers have found our trac site so it is almost useless. :(
>>> Hopefully I can move it to another host soon...  Is anyone interested in
>>> helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!
>>>
>> What about redmine? My wife told me she would setup a redmine plus
>> akismet spam filtering for my new project. Would be a honor for
>> us to also host gnutls. We are using a Xen-based virtual server on
>> gandi.net.
> 
> Thanks for offering!  I have not used redmine...  I'll take a look.  If
> others have thoughts about it, that would be appreciated as well.
> 
> I think what we need is a wiki and bug/issue-tracking with good
> roadmap-tracking of each bug/issue.
> 
> Alternatively, I'll check prices for VPS's too, possibly I can donate
> some funding to the gnutls project to keep a small VPS running.
> 
> /Simon

I just got my first redmine hosting working. Redmine is basically trac
on steroids. It provides an admin interface including editing users,
roles and projects by default.
See this: http://libpona.cyblogic.com/
I had to get some extra patches to make the git support working more
smoothly. Spamming using the ticket system is not that easy in redmine,
because usually you have to sign-up first (easily), before you can
write a new issue.

--
Frank




From ametzler at downhill.at.eu.org  Sun Jun 15 09:20:06 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 15 Jun 2008 09:20:06 +0200
Subject: Bug#486269: gnutls26_2.3.14-1(experimental/amd64/xenophanes):
	FTBFS: Time out while doing checks
In-Reply-To: <87skvfwy03.fsf@pindar.marcbrockschmidt.de>
Message-ID: <20080615072006.GA3776@downhill.g.la>

On 2008-06-14 Marc 'HE' Brockschmidt <marc at marcbrockschmidt.de> wrote:
[...]
> | Checking OpenPGP certificate verification
> | Cannot connect to 127.0.0.2:5557: Connection refused
> | Cannot connect to 127.0.0.2:5557: Connection refused
> | Cannot connect to 127.0.0.2:5557: Connection refused
[...]
> http://experimental.debian.net/build.php?arch=amd64&pkg=gnutls26&ver=2.3.14-1

> I'm not sure what service you are trying to connect to, but obviously,
> it doesn't work as expected. Other buildds showed the same problem.

Hello,

it is the shellscript tests/openpgp-certs/testcerts
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob_plain;f=tests/openpgp-certs/testcerts;hb=d44ffe657ea8c86e4836fbf824e65b40db0346b4
[1]

It is starting a listening daemon on 0.0.0.0:5557. Then a client is
connecting to the server on "localhost", 127.0.0.1 and 127.0.0.2.
The point of the exercise is certificate verification, the cert used
is limited to "127.0.0.1".

I am aware that e.g. in linux vserver 127.0.0.1 is not useable
(127.0.0.1 is the loopback address of the host system, and
therefore a daemon running in the vserver cannot bind to it.), but
I thought this was not a limitation of our buildd network.

Anyway, since gnutls-cli's exitcode is 1 both for verification failed
and connection refused, I do not see a better alternative than
disabling this test on the buildds.

cu andreas

[1]
(This is a slightly older version of the script. The version in 2.3.14
is functionally identical, except for using port 5557 instead of 5556.
No idea why git*web* is out of date, the git repo itself is ok.)

-- 
`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  Sun Jun 15 23:03:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 15 Jun 2008 23:03:27 +0200
Subject: GnuTLS 2.3.14 - third release candidate for 2.4.0
In-Reply-To: <87skvipv6k.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Thu, 12 Jun 2008 10:46:59 -0400")
References: <87r6b5j5fe.fsf@mocca.josefsson.org>
	<87skvipv6k.fsf@squeak.fifthhorseman.net>
Message-ID: <87lk162yxs.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Tue 2008-06-10 18:23:01 -0400, Simon Josefsson wrote:
>
>> * Version 2.3.14 (released 2008-06-11)
>>
>> ** libgnutls [OpenPGP]: Changed OpenPGP verification behaviour.
>> An OpenPGP certificate is now only considered verified if all the user
>> IDs are verified.
>
> I've tested this change against Andreas Metzler's debian packaging of
> 2.3.14, and it looks correct.  A single unverifiable User ID on the
> certificate causes verification failure.  This "fail closed" behavior
> is significantly better than the earlier "fail open" behavior.
> Thanks!
>
> Hopefully for gnutls 2.6 we can cook up more nuanced OpenPGP
> certificate verification, where irrelevant unverified UserIDs don't
> cause a failure.
>
> Thanks for all the work on this,

Great.  Thanks for confirming the status.  I think we are ready for
2.4.0, but I'll do another release candidate now to make sure.

/Simon




From simon at josefsson.org  Sun Jun 15 23:05:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 15 Jun 2008 23:05:16 +0200
Subject: openpgp-certs failure under wine
In-Reply-To: <c331d99a0806120321q23e9330foe1d1fd70b60f4929@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 12 Jun 2008 13:21:17
	+0300")
References: <87r6b5j5fe.fsf@mocca.josefsson.org>
	<87mylsict4.fsf@mocca.josefsson.org>
	<c331d99a0806120321q23e9330foe1d1fd70b60f4929@mail.gmail.com>
Message-ID: <87hcbu2yur.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

>> Tracing it further, it seems it OpenCDK is returning EOF when parsing
>> the OpenPGP key, I'm not sure why.
>>
>> Nikos, can you reproduce this?  You'll need to install mingw32, wine,
>> binfmt-support and run ./configure --host=i586-mingw32msvc
>> --build=i686-pc-linux-gnu if you are using debian.
>
> Unfortunately not. gnutls couldn't compile with the setup (something
> about missing libgcrypt etc).
>
>> I'm leaving now, but will look into this next week unless you or someone
>> else has had time to debug it.
>
> I'm also leaving for holidays today so I'll be unable to work on this soon.

It seems the self-test also fails under Debian buildds:

http://bugs.debian.org/486269

I guess the use of 127.0.0.2 isn't portable?

Anyway, I think the simplest thing to do is to disable the self-test for
now, it was added too late in the release cycle and we don't have time
to work out the problems with it.  We can fix it in the 2.5.x branch.

/Simon




From simon at josefsson.org  Sun Jun 15 23:59:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 15 Jun 2008 23:59:45 +0200
Subject: GnuTLS 2.3.15 - fourth and final (?) release candidate for 2.4.0
Message-ID: <87abhm2wby.fsf@mocca.josefsson.org>

Version 2.3.15 will hopefully be the final release candidate for the
next stable release v2.4.0.  Please test v2.3.15 as if it were a stable
release!  I'm cc'ing help-gnutls as well, to reach wider audience.
Please report problems to gnutls-devel only.

See below for the v2.4.0 release notes, comments and suggestions are
welcome!

This weekend is Midsommar in Sweden, and I'm leaving town on Thursday,
thus expect the final 2.4.0 release on Thursday.

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

Here is the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.3.15.exe
  http://josefsson.org/gnutls4win/gnutls-2.3.15.zip

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb

What's New
==========

Major end-user visible changes compared to the v2.2 branch:

* The PSK sub-system has been improved and now supports password
  derivation and PSK identity hints.

  The password derivation algorithms support is documented in
  draft-ietf-netconf-tls-02.txt.

* The certtool --inder and --outder has been replaced by --inraw and --outraw.

  This aligns terminology with OpenPGP, which doesn't use DER
  encoding.  The old parameters will continue to work for some time.

* Certtool now confirm passwords and changes permissions of private key files.

* The default handshake size limit has been increased to 48kb.

  It appears as if some valid handshakes are large due to sending many
  CA certificates.  (The earlier limit was 16kb.)

* LZO compression is now disabled by default.

  The main reason is that LZO compression in TLS is not standardized,
  but license compatiblity issues with minilzo triggered us to make
  this decision now.

* Improvements for cross-compilation to Windows and OpenWRT.

* The look of the GTK-DOC manual has been improved.

Major developer visible changes compared to the v2.2 branch:

* Full OpenPGP support is part of libgnutls, licensed under the LGPL.

* New APIs to access the raw X.509 Subject and Issuer DN's and
  elements from the certificate credentials structure, thanks to Joe
  Orton.

* New APIs to improve working with username/passwords and PSK.

* Names of constants to affect certificate printing changed.

  The constants are used for OpenPGP too, which the names didn't
  reflect, so the following name change has been made:

            Old name                         New name
     GNUTLS_X509_CRT_FULL            GNUTLS_CRT_PRINT_FULL
     GNUTLS_X509_CRT_ONELINE         GNUTLS_CRT_PRINT_ONELINE
     GNUTLS_X509_CRT_UNSIGNED_FULL   GNUTLS_CRT_PRINT_UNSIGNED_FULL

  The old names will be mapped to the new names for some time.

* The function gnutls_openpgp_privkey_get_id has been renamed to
  gnutls_openpgp_privkey_get_key_id.

* Replaced all uses of alloca with malloc and free.

* We no longer build with -D_REENTRANT -D_THREAD_SAFE.

  We have been unable to find a documented rationale for this
  practice.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.4
=============================

All OpenPGP functions have been moved from libgnutls-extra to
libgnutls, and several new functions have been added (see below).
Before making the release, we discussed whether moving functions from
libgnutls-extra to libgnutls would require us to increment the ABI
version, but the general opinion was that this would not be required.
All older functions continue to work the same.  We are open to the
possibility that this decision will lead to problem on some platform,
and if it turns out that the Right Thing should have been to increment
the shared library version, we would need to release an update within
the 2.4.x branch that increments the shared library version.

This release adds the following functions:

  gnutls_psk_client_get_hint
  gnutls_psk_set_server_credentials_hint
  gnutls_psk_netconf_derive_key

    Used to get/set the PSK identity hint, and derive PSK keys from
    passwords a'la netconf.

  gnutls_x509_dn_deinit
  gnutls_x509_dn_export
  gnutls_x509_dn_import
  gnutls_x509_dn_init

    Used to handle X.509 Certificate DN's directly.

  gnutls_hex2bin

    Converts a data buffer to hex.  Useful for handling PSK/SRP shared
    secrets.

  gnutls_certificate_get_x509_cas
  gnutls_certificate_get_x509_crls
  gnutls_certificate_get_openpgp_keyring

    Functions for direct access to credential elements.

  gnutls_openpgp_crt_get_auth_subkey
  gnutls_openpgp_crt_get_key_id
  gnutls_openpgp_crt_get_pk_dsa_raw
  gnutls_openpgp_crt_get_pk_rsa_raw
  gnutls_openpgp_crt_get_preferred_key_id
  gnutls_openpgp_crt_get_revoked_status
  gnutls_openpgp_crt_get_subkey_count
  gnutls_openpgp_crt_get_subkey_creation_time
  gnutls_openpgp_crt_get_subkey_expiration_time
  gnutls_openpgp_crt_get_subkey_id
  gnutls_openpgp_crt_get_subkey_idx
  gnutls_openpgp_crt_get_subkey_pk_algorithm
  gnutls_openpgp_crt_get_subkey_pk_dsa_raw
  gnutls_openpgp_crt_get_subkey_pk_rsa_raw
  gnutls_openpgp_crt_get_subkey_revoked_status
  gnutls_openpgp_crt_get_subkey_usage
  gnutls_openpgp_crt_print
  gnutls_openpgp_crt_set_preferred_key_id
  gnutls_openpgp_keyring_get_crt
  gnutls_openpgp_keyring_get_crt_count
  gnutls_openpgp_privkey_export
  gnutls_openpgp_privkey_export_dsa_raw
  gnutls_openpgp_privkey_export_rsa_raw
  gnutls_openpgp_privkey_export_subkey_dsa_raw
  gnutls_openpgp_privkey_export_subkey_rsa_raw
  gnutls_openpgp_privkey_get_fingerprint
  gnutls_openpgp_privkey_get_key_id
  gnutls_openpgp_privkey_get_pk_algorithm
  gnutls_openpgp_privkey_get_preferred_key_id
  gnutls_openpgp_privkey_get_revoked_status
  gnutls_openpgp_privkey_get_subkey_count
  gnutls_openpgp_privkey_get_subkey_creation_time
  gnutls_openpgp_privkey_get_subkey_expiration_time
  gnutls_openpgp_privkey_get_subkey_id
  gnutls_openpgp_privkey_get_subkey_idx
  gnutls_openpgp_privkey_get_subkey_pk_algorithm
  gnutls_openpgp_privkey_get_subkey_revoked_status
  gnutls_openpgp_privkey_set_preferred_key_id

    New OpenPGP related functions.

    The function gnutls_openpgp_crt_get_key_id is the same as the old
    from gnutls_openpgp_crt_get_id, see above.

The release also adds a new header file 'gnutls/crypto.h', however it
is currently not used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080615/8281921e/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Mon Jun 16 07:12:37 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Jun 2008 01:12:37 -0400
Subject: openpgp fingerprints for subkeys
Message-ID: <87prqim08q.fsf@squeak.fifthhorseman.net>

Hey Folks--

Another thought about OpenPGP certificate/key infrastructure (i'm
submitting this here because the trac installation seems to be defunct
From the spam, and i'm not sure what the rightful heir is).

gnutls_openpgp_privkey_get_fingerprint() and
gnutls_openpgp_crt_get_fingerprint() both are capable of returning the
fingerprint of the primary key.  However, subkeys can have
fingerprints too, and in many circumstances it can be useful to
calculate the subkey's fingerprint.

Having a parallel subkey-specific fingerprint function would be good.

If you want to verify the subkey fingerprint calculations, you can see
them emitted with gpg with two --fingerprint options:

 gpg --fingerprint --fingerprint --list-key "$KEYID"

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080616/c34079f2/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Mon Jun 16 07:57:48 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Jun 2008 01:57:48 -0400
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
Message-ID: <87lk15ncpv.fsf@squeak.fifthhorseman.net>

Hey folks--

This message describes some thoughts about the GnuTLS OpenPGP API (in
particular, the bits that used to be OpenCDK).  These thoughts have
come after i've played with the library for a while, but they may
still be ill-informed.  I'd be happy to have flaws in my reasoning
pointed out.  My first observation was dismay at just how many
functions were specifically available for the OpenPGP key management
functionality.  The OpenPGP function reference [0] is enormous and
difficult to wade through.  Furthermore, much functionality seems
duplicated (or quadruplicated!) across different functions, which can
make it difficult to write clean, simple code with the library.

What follows are some proposals that might simplify and streamline the
set of functions available, which would make it easier for a skimming
developer to get a sense of the main functionality offered by the
library, and would facilitate writing tighter code in scenarios where
certain aspects might be better treated as abstractions.

Primary Keys vs. Subkeys
------------------------

There are currently a lot of duplicated functions which deal with the
subkey and primary keys differently.  For example:

 gnutls_openpgp_crt_get_pk_algorithm()
 gnutls_openpgp_crt_get_subkey_pk_algorithm()

These behave exactly the same way, but the primary key is sort of
special-cased out.

When writing key management code, one often abstracts away the
differences between primary keys and subkeys, and needs to just walk
through each key separately.  Having to call different functions for
the subkey than for the primary key is awkward and makes for a lot of
code duplication, which is room for error.

We could significantly reduce the number of functions exposed by
GnuTLS if we were to collapse these pairs of functions into a single
function which takes a key index.  Key index 0 would be the primary
key, key index 1 would be the first subkey, etc.  This would allow
much simpler looping constructs over a keyset, and would make the
documentation easier to scan and understand.

Certificates vs. Private Keys
-----------------------------

Furthermore, there are many functions that have basically identical
functionality duplicated across the crt and the privkey.  I'm aware
that these functions may be created as duplicates of the functions in
the x509 space, but if the crt and the privkey shared a common base
struct, or were otherwise considered interchangable at some level, you
could reduce the function space still further.

Conclusions, and a Proposal
---------------------------

I'm aware that major changes in API (esp. removing named functions)
are strongly discouraged in a stable library, so i can understand not
wanting to deal with this.  But getting developers to adopt the
OpenPGP model is going to be difficult enough without forcing those
developers to understand and work around this kind of duplicated
interface.

Not all of these changes are necessarily desirable, of course, but i
wanted to raise the issue of how such a re-configured library might
look so we can consider the merits and disadvantages of the
arrangement.  It's also possible that a documentation overhaul could
help for the "skimming/crammming developer" scenario (though it
wouldn't help much in terms of writing code that deals with
subkeys/primary keys at a similar level of abstraction).

I'd be happy to implement a sort of shim/wrapper library around
gnutls's OpenPGP key management pieces, so people can get a sense of
what that might look like.  I believe i can do this with no loss in
functionality, and a significant reduction in the number of functions
just from merging primary key/subkey functionality alone.  I'm not
sure how to handle the crt/privkey parallels, but if other people have
suggestions, i'd welcome them.

Thanks for considering this feedback,

       --dkg

PS i'm aware that these ideas cannot be under consideration for 2.4,
   given the current timeline.  I still think it's worth bringing them
   up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080616/4268acd7/attachment.pgp>

From simon at josefsson.org  Mon Jun 16 11:55:51 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 11:55:51 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87prqim08q.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 01:12:37 -0400")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
Message-ID: <87tzftzot4.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Hey Folks--
>
> Another thought about OpenPGP certificate/key infrastructure (i'm
> submitting this here because the trac installation seems to be defunct
> From the spam, and i'm not sure what the rightful heir is).

Hi!  This list is the best place for now...

> gnutls_openpgp_privkey_get_fingerprint() and
> gnutls_openpgp_crt_get_fingerprint() both are capable of returning the
> fingerprint of the primary key.  However, subkeys can have
> fingerprints too, and in many circumstances it can be useful to
> calculate the subkey's fingerprint.

Makes sense.

> Having a parallel subkey-specific fingerprint function would be good.
>
> If you want to verify the subkey fingerprint calculations, you can see
> them emitted with gpg with two --fingerprint options:
>
>  gpg --fingerprint --fingerprint --list-key "$KEYID"

Is it easy to implement this?  I think we could squeeze this addition
into 2.4.0 if you or Nikos come up with a patch soon.

/Simon




From simon at josefsson.org  Mon Jun 16 12:07:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 12:07:27 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <87lk15ncpv.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 01:57:48 -0400")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
Message-ID: <87prqhzo9s.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Hey folks--
>
> This message describes some thoughts about the GnuTLS OpenPGP API (in
> particular, the bits that used to be OpenCDK).  These thoughts have
> come after i've played with the library for a while, but they may
> still be ill-informed.  I'd be happy to have flaws in my reasoning
> pointed out.  My first observation was dismay at just how many
> functions were specifically available for the OpenPGP key management
> functionality.

Hi!  Thanks for discussing this.

> The OpenPGP function reference [0] is enormous and difficult to wade
> through. Furthermore, much functionality seems duplicated (or
> quadruplicated!)  across different functions, which can make it
> difficult to write clean, simple code with the library.

Agreed.

> What follows are some proposals that might simplify and streamline the
> set of functions available, which would make it easier for a skimming
> developer to get a sense of the main functionality offered by the
> library, and would facilitate writing tighter code in scenarios where
> certain aspects might be better treated as abstractions.
>
> Primary Keys vs. Subkeys
> ------------------------
>
> There are currently a lot of duplicated functions which deal with the
> subkey and primary keys differently.  For example:
>
>  gnutls_openpgp_crt_get_pk_algorithm()
>  gnutls_openpgp_crt_get_subkey_pk_algorithm()
>
> These behave exactly the same way, but the primary key is sort of
> special-cased out.
>
> When writing key management code, one often abstracts away the
> differences between primary keys and subkeys, and needs to just walk
> through each key separately.  Having to call different functions for
> the subkey than for the primary key is awkward and makes for a lot of
> code duplication, which is room for error.
>
> We could significantly reduce the number of functions exposed by
> GnuTLS if we were to collapse these pairs of functions into a single
> function which takes a key index.  Key index 0 would be the primary
> key, key index 1 would be the first subkey, etc.  This would allow
> much simpler looping constructs over a keyset, and would make the
> documentation easier to scan and understand.

I think this suggestion makes sense, although I'm not an OpenPGP expert.
I have also found the number of APIs related to keys+subkeys rather
overwhelming.

> Certificates vs. Private Keys
> -----------------------------
>
> Furthermore, there are many functions that have basically identical
> functionality duplicated across the crt and the privkey.  I'm aware
> that these functions may be created as duplicates of the functions in
> the x509 space, but if the crt and the privkey shared a common base
> struct, or were otherwise considered interchangable at some level, you
> could reduce the function space still further.

I agree that duplicated functionality is quite bad, but having a
separate type for private keys can be useful if you want to perform a
code review of all code dealing with the private keys only.  There could
be ideas that harmonize these two priorities though.

> Conclusions, and a Proposal
> ---------------------------
>
> I'm aware that major changes in API (esp. removing named functions)
> are strongly discouraged in a stable library, so i can understand not
> wanting to deal with this.  But getting developers to adopt the
> OpenPGP model is going to be difficult enough without forcing those
> developers to understand and work around this kind of duplicated
> interface.

I think the size of the installed base for the OpenPGP stuff is rather
limited, so I'm quite open to improving the API in this area.  We should
make an effort to maintain ABI compatibility though.

> Not all of these changes are necessarily desirable, of course, but i
> wanted to raise the issue of how such a re-configured library might
> look so we can consider the merits and disadvantages of the
> arrangement.  It's also possible that a documentation overhaul could
> help for the "skimming/crammming developer" scenario (though it
> wouldn't help much in terms of writing code that deals with
> subkeys/primary keys at a similar level of abstraction).

Better documentation is always good.

> I'd be happy to implement a sort of shim/wrapper library around
> gnutls's OpenPGP key management pieces, so people can get a sense of
> what that might look like.  I believe i can do this with no loss in
> functionality, and a significant reduction in the number of functions
> just from merging primary key/subkey functionality alone.  I'm not
> sure how to handle the crt/privkey parallels, but if other people have
> suggestions, i'd welcome them.

Hm.  Maybe we can add a libgnutls-openpgp which contains a simplified
OpenPGP related API?  Eventually, the old OpenPGP API in libgnutls could
be deprecated.

In general, I would prefer if libgnutls is a minimal TLS library
implementation, and there would be libgnutls-openpgp and libgnutls-x509
with the OpenPGP/X.509 functionality.  Not everyone needs X.509/OpenPGP.
Your ideas to have a OpenPGP wrapper library would tie well into my
wishes here.

One problem is the internal crypto abstraction interface: but if we make
that API publicly available, the libgnutls-foo libraries can access them
as well.  Applications can too.

> PS i'm aware that these ideas cannot be under consideration for 2.4,
>    given the current timeline.  I still think it's worth bringing them
>    up.

Definitely, and thanks for doing that.

/Simon




From n.mavrogiannopoulos at gmail.com  Mon Jun 16 15:41:06 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 16 Jun 2008 15:41:06 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87tzftzot4.fsf@mocca.josefsson.org>
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>

On Mon, Jun 16, 2008 at 11:55 AM, Simon Josefsson <simon at josefsson.org> wrote:
> Makes sense.
>
>> Having a parallel subkey-specific fingerprint function would be good.
>>
>> If you want to verify the subkey fingerprint calculations, you can see
>> them emitted with gpg with two --fingerprint options:
>>
>>  gpg --fingerprint --fingerprint --list-key "$KEYID"
>
> Is it easy to implement this?  I think we could squeeze this addition
> into 2.4.0 if you or Nikos come up with a patch soon.

Could be easy but please do not delay the 2.4.0 for this. The merging
of development with my branch is already very difficult!  Such a
function can be easily implemented at any point (currently I'm not
home so I cannot provide a quick patch).

regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Mon Jun 16 15:53:59 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 16 Jun 2008 15:53:59 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <87prqhzo9s.fsf@mocca.josefsson.org>
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>

On Mon, Jun 16, 2008 at 12:07 PM, Simon Josefsson <simon at josefsson.org> wrote:

>> Primary Keys vs. Subkeys
>> ------------------------
>>
>> There are currently a lot of duplicated functions which deal with the
>> subkey and primary keys differently.  For example:
>>
>>  gnutls_openpgp_crt_get_pk_algorithm()
>>  gnutls_openpgp_crt_get_subkey_pk_algorithm()
>>
>> These behave exactly the same way, but the primary key is sort of
>> special-cased out.
>>
>> When writing key management code, one often abstracts away the
>> differences between primary keys and subkeys, and needs to just walk
>> through each key separately.  Having to call different functions for
>> the subkey than for the primary key is awkward and makes for a lot of
>> code duplication, which is room for error.
>>
>> We could significantly reduce the number of functions exposed by
>> GnuTLS if we were to collapse these pairs of functions into a single
>> function which takes a key index.  Key index 0 would be the primary
>> key, key index 1 would be the first subkey, etc.  This would allow
>> much simpler looping constructs over a keyset, and would make the
>> documentation easier to scan and understand.
>
> I think this suggestion makes sense, although I'm not an OpenPGP expert.
> I have also found the number of APIs related to keys+subkeys rather
> overwhelming.

Actually the idea was to replace them completely. But since we wanted
backwards compatibility, this is the reason of the
non subkey functions still existing. A change would still be possible
by deprecating the non subkey functions and adding functionality to
the subkey ones so they handle primary keys as well. However this is a
big change for last minute change. (although I like this change).

If this is to occur I'd suggest to delay the release for another 1-2
months and merge with the other development branch. Otherwise with
these changes merging would be impossible.

>> Certificates vs. Private Keys
>> -----------------------------
>>
>> Furthermore, there are many functions that have basically identical
>> functionality duplicated across the crt and the privkey.  I'm aware
>> that these functions may be created as duplicates of the functions in
>> the x509 space, but if the crt and the privkey shared a common base
>> struct, or were otherwise considered interchangable at some level, you
>> could reduce the function space still further.

This is quite unavoidable. I wanted to have a consistent API for X.509
and Openpgp keys. If this changes consistency is pretty much gone!

> I think the size of the installed base for the OpenPGP stuff is rather
> limited, so I'm quite open to improving the API in this area.  We should
> make an effort to maintain ABI compatibility though.

Well I think currently this is a dilema. It is not easy to have both
non duplicated functions a backwards compatibility. The previous
interface was quite limited.

> Hm.  Maybe we can add a libgnutls-openpgp which contains a simplified
> OpenPGP related API?  Eventually, the old OpenPGP API in libgnutls could
> be deprecated.

I don't think it is a good idea to offer alternative APIs. I'm in
favor for either a fix in the library, or a delay until the next ABI
break.

regards,
Nikos




From simon at josefsson.org  Mon Jun 16 15:56:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 15:56:13 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 16 Jun 2008 15:41:06
	+0200")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
Message-ID: <87wskpjxfm.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Mon, Jun 16, 2008 at 11:55 AM, Simon Josefsson <simon at josefsson.org> wrote:
>> Makes sense.
>>
>>> Having a parallel subkey-specific fingerprint function would be good.
>>>
>>> If you want to verify the subkey fingerprint calculations, you can see
>>> them emitted with gpg with two --fingerprint options:
>>>
>>>  gpg --fingerprint --fingerprint --list-key "$KEYID"
>>
>> Is it easy to implement this?  I think we could squeeze this addition
>> into 2.4.0 if you or Nikos come up with a patch soon.
>
> Could be easy but please do not delay the 2.4.0 for this. The merging
> of development with my branch is already very difficult!  Such a
> function can be easily implemented at any point (currently I'm not
> home so I cannot provide a quick patch).

That new API can go into a 2.4.1 as well.  I don't see a reason not to
release 2.4.0 on schedule on Thursday.

/Simon




From simon at josefsson.org  Mon Jun 16 16:03:35 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 16:03:35 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 16 Jun 2008 15:53:59
	+0200")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
	<c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
Message-ID: <87skvdjx3c.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Mon, Jun 16, 2008 at 12:07 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
>>> Primary Keys vs. Subkeys
>>> ------------------------
>>>
>>> There are currently a lot of duplicated functions which deal with the
>>> subkey and primary keys differently.  For example:
>>>
>>>  gnutls_openpgp_crt_get_pk_algorithm()
>>>  gnutls_openpgp_crt_get_subkey_pk_algorithm()
>>>
>>> These behave exactly the same way, but the primary key is sort of
>>> special-cased out.
>>>
>>> When writing key management code, one often abstracts away the
>>> differences between primary keys and subkeys, and needs to just walk
>>> through each key separately.  Having to call different functions for
>>> the subkey than for the primary key is awkward and makes for a lot of
>>> code duplication, which is room for error.
>>>
>>> We could significantly reduce the number of functions exposed by
>>> GnuTLS if we were to collapse these pairs of functions into a single
>>> function which takes a key index.  Key index 0 would be the primary
>>> key, key index 1 would be the first subkey, etc.  This would allow
>>> much simpler looping constructs over a keyset, and would make the
>>> documentation easier to scan and understand.
>>
>> I think this suggestion makes sense, although I'm not an OpenPGP expert.
>> I have also found the number of APIs related to keys+subkeys rather
>> overwhelming.
>
> Actually the idea was to replace them completely. But since we wanted
> backwards compatibility, this is the reason of the
> non subkey functions still existing. A change would still be possible
> by deprecating the non subkey functions and adding functionality to
> the subkey ones so they handle primary keys as well. However this is a
> big change for last minute change. (although I like this change).
>
> If this is to occur I'd suggest to delay the release for another 1-2
> months and merge with the other development branch. Otherwise with
> these changes merging would be impossible.

I think we shouldn't loose the opportunity to do a stable release now,
we are in pretty good state.  There are many users that don't care about
the OpenPGP stuff, and delaying things would just because it is possible
to do things better would delay us indefinitely.

>> I think the size of the installed base for the OpenPGP stuff is rather
>> limited, so I'm quite open to improving the API in this area.  We should
>> make an effort to maintain ABI compatibility though.
>
> Well I think currently this is a dilema. It is not easy to have both
> non duplicated functions a backwards compatibility. The previous
> interface was quite limited.
>
>> Hm.  Maybe we can add a libgnutls-openpgp which contains a simplified
>> OpenPGP related API?  Eventually, the old OpenPGP API in libgnutls could
>> be deprecated.
>
> I don't think it is a good idea to offer alternative APIs. I'm in
> favor for either a fix in the library, or a delay until the next ABI
> break.

The duplicated functions would only be there during a transition period,
so I think it could work.  The current API could be re-implemented using
the new API.  I think we are stuck with supporting the current OpenPGP
API for the next few years regardless of what we do.  Isolating those
functions into a "compat" style package could help us avoid ugly code.

I don't have time to work on the OpenPGP stuff actively, so I'm relying
on you, Daniel and others to do the work here.

/Simon




From dkg-debian.org at fifthhorseman.net  Mon Jun 16 16:21:43 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Jun 2008 10:21:43 -0400
Subject: openpgp fingerprints for subkeys
In-Reply-To: <c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon\,
	16 Jun 2008 15\:41\:06 +0200")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
Message-ID: <87wskpihoo.fsf@squeak.fifthhorseman.net>

On Mon 2008-06-16 09:41:06 -0400, Nikos Mavrogiannopoulos wrote:

> On Mon, Jun 16, 2008 at 11:55 AM, Simon Josefsson <simon at josefsson.org> wrote:
>
>> Is it easy to implement this?  I think we could squeeze this
>> addition into 2.4.0 if you or Nikos come up with a patch soon.
>
> Could be easy but please do not delay the 2.4.0 for this. The
> merging of development with my branch is already very difficult!
> Such a function can be easily implemented at any point (currently
> I'm not home so I cannot provide a quick patch).

Attached, please find a patch to provide this functionality.  I've
tested it locally against private keys and certificates, and it seems
to work.  I still don't understand the test infrastructure, though, so
i haven't added a test, unfortunately.

Feedback on the patch is welcome.  I'm afraid it's a bit of a
cargo-cult patch (a fair bit of copy/paste from similar functions),
and it further aggravates the other concern i wrote about having too
many duplicate OpenPGP functions.  But it produces the correct
fingerprints for me.

Regards,

        --dkg

PS i also fixed a misleading comment in one of the existing
   fingerprint function headers.  Sorry to have two things in one
   patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: subkey_fingerprints.patch
Type: text/x-diff
Size: 4686 bytes
Desc: adding the ability to compute subkey fingerprints
URL: </pipermail/attachments/20080616/ec824b13/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080616/ec824b13/attachment.pgp>

From wk at gnupg.org  Mon Jun 16 16:30:07 2008
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Jun 2008 16:30:07 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 16 Jun 2008 15:53:59
	+0200")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
	<c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
Message-ID: <87y7555u6o.fsf@wheatstone.g10code.de>

On Mon, 16 Jun 2008 15:53, n.mavrogiannopoulos at gmail.com said:

> This is quite unavoidable. I wanted to have a consistent API for X.509
> and Openpgp keys. If this changes consistency is pretty much gone!

It is probably too late now but you might want to look at the gpgme
interface for keys.  It is now in active use for 5 years.  For example,
retrieving all fingerprints of a key is a mere list walking.

By having the gnutls API similar to the one of gpgme it will make the
life of developers much easier.  You could just take the structure
definitions out of gpgme and use the same definition under a different
name in gnutls.

Just my 2 cents,

  Werner

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





From simon at josefsson.org  Mon Jun 16 19:35:32 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 19:35:32 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <87y7555u6o.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Mon, 16 Jun 2008 16:30:07 +0200")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
	<c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
	<87y7555u6o.fsf@wheatstone.g10code.de>
Message-ID: <87tzft2sgr.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Mon, 16 Jun 2008 15:53, n.mavrogiannopoulos at gmail.com said:
>
>> This is quite unavoidable. I wanted to have a consistent API for X.509
>> and Openpgp keys. If this changes consistency is pretty much gone!
>
> It is probably too late now but you might want to look at the gpgme
> interface for keys.  It is now in active use for 5 years.  For example,
> retrieving all fingerprints of a key is a mere list walking.
>
> By having the gnutls API similar to the one of gpgme it will make the
> life of developers much easier.  You could just take the structure
> definitions out of gpgme and use the same definition under a different
> name in gnutls.

Making it simple for gpgme applications to use gnutls' openpgp stuff
would be very cool.  Some alignment of the APIs here may be possible.
Is GPGME under the LGPL so it can be used by libgnutls?

Alas, I don't have time to work on it any time soon. :(

/Simon




From simon at josefsson.org  Mon Jun 16 21:36:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jun 2008 21:36:03 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87wskpihoo.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 10:21:43 -0400")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
Message-ID: <87abhl895o.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Mon 2008-06-16 09:41:06 -0400, Nikos Mavrogiannopoulos wrote:
>
>> On Mon, Jun 16, 2008 at 11:55 AM, Simon Josefsson <simon at josefsson.org> wrote:
>>
>>> Is it easy to implement this?  I think we could squeeze this
>>> addition into 2.4.0 if you or Nikos come up with a patch soon.
>>
>> Could be easy but please do not delay the 2.4.0 for this. The
>> merging of development with my branch is already very difficult!
>> Such a function can be easily implemented at any point (currently
>> I'm not home so I cannot provide a quick patch).
>
> Attached, please find a patch to provide this functionality.  I've
> tested it locally against private keys and certificates, and it seems
> to work.  I still don't understand the test infrastructure, though, so
> i haven't added a test, unfortunately.
>
> Feedback on the patch is welcome.  I'm afraid it's a bit of a
> cargo-cult patch (a fair bit of copy/paste from similar functions),
> and it further aggravates the other concern i wrote about having too
> many duplicate OpenPGP functions.  But it produces the correct
> fingerprints for me.

It looks small and harmless.  I think we should add it before v2.4.0.
Have you signed copyright papers with FSF?  My fencepost.gnu.org account
doesn't seem to work so I can't check it...  A copyright transfer is
required to use your work.  If not I can send you the forms offline.  If
you agree to sign them, I don't think we need to hold up the release
before the FSF has received your papers.

/Simon




From dkg-debian.org at fifthhorseman.net  Mon Jun 16 23:36:57 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Jun 2008 17:36:57 -0400
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87abhl895o.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon\, 16 Jun 2008 21\:36\:03 +0200")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
	<87abhl895o.fsf@mocca.josefsson.org>
Message-ID: <873andav14.fsf@squeak.fifthhorseman.net>

On Mon 2008-06-16 15:36:03 -0400, Simon Josefsson wrote:

> It looks small and harmless.  I think we should add it before
> v2.4.0.  Have you signed copyright papers with FSF?  My
> fencepost.gnu.org account doesn't seem to work so I can't check
> it...  A copyright transfer is required to use your work.  If not I
> can send you the forms offline.  If you agree to sign them, I don't
> think we need to hold up the release before the FSF has received
> your papers.

Sounds good to me.  I've never signed copyright assignment papers with
the FSF, but i have no problem assigning copyright for my GnuTLS
OpenPGP subkey-fingerprinting patch to the FSF.  Send me whatever you
need for that to take effect, and i'll take care of it.

Thanks for being so responsive on this during your time off.  I'm
looking forward to the 2.4.0 release.

Regards,

     --dkg

PS as far as i'm concerned, this publically-stated, OpenPGP-signed,
   published electronic message carries more weight than any forgeable
   dead-tree silliness, but i'm happy to take equivalent formal and/or
   archaic steps to smooth things out if other folks think they're
   needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080616/ce8063dc/attachment.pgp>

From dkg at fifthhorseman.net  Mon Jun 16 23:36:57 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 16 Jun 2008 17:36:57 -0400
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87abhl895o.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon\, 16 Jun 2008 21\:36\:03 +0200")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
	<87abhl895o.fsf@mocca.josefsson.org>
Message-ID: <874p7tcb9i.fsf@squeak.fifthhorseman.net>

On Mon 2008-06-16 15:36:03 -0400, Simon Josefsson wrote:

> It looks small and harmless.  I think we should add it before
> v2.4.0.  Have you signed copyright papers with FSF?  My
> fencepost.gnu.org account doesn't seem to work so I can't check
> it...  A copyright transfer is required to use your work.  If not I
> can send you the forms offline.  If you agree to sign them, I don't
> think we need to hold up the release before the FSF has received
> your papers.

Sounds good to me.  I've never signed copyright assignment papers with
the FSF, but i have no problem assigning copyright for my GnuTLS
OpenPGP subkey-fingerprinting patch to the FSF.  Send me whatever you
need for that to take effect, and i'll take care of it.

Thanks for being so responsive on this during your time off.  I'm
looking forward to the 2.4.0 release.

Regards,

     --dkg

PS as far as i'm concerned, this publically-stated, OpenPGP-signed,
   published electronic message carries more weight than any forgeable
   dead-tree silliness, but i'm happy to take equivalent formal and/or
   archaic steps to smooth things out if other folks think they're
   needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080616/efc08e23/attachment.pgp>

From simon at josefsson.org  Tue Jun 17 01:14:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Jun 2008 01:14:26 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <874p7tcb9i.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 17:36:57 -0400")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
	<87abhl895o.fsf@mocca.josefsson.org>
	<874p7tcb9i.fsf@squeak.fifthhorseman.net>
Message-ID: <87d4mh6kh9.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Mon 2008-06-16 15:36:03 -0400, Simon Josefsson wrote:
>
>> It looks small and harmless.  I think we should add it before
>> v2.4.0.  Have you signed copyright papers with FSF?  My
>> fencepost.gnu.org account doesn't seem to work so I can't check
>> it...  A copyright transfer is required to use your work.  If not I
>> can send you the forms offline.  If you agree to sign them, I don't
>> think we need to hold up the release before the FSF has received
>> your papers.
>
> Sounds good to me.  I've never signed copyright assignment papers with
> the FSF, but i have no problem assigning copyright for my GnuTLS
> OpenPGP subkey-fingerprinting patch to the FSF.  Send me whatever you
> need for that to take effect, and i'll take care of it.

Sent privately, thank you.

> Thanks for being so responsive on this during your time off.  I'm
> looking forward to the 2.4.0 release.

Me too! :)

> PS as far as i'm concerned, this publically-stated, OpenPGP-signed,
>    published electronic message carries more weight than any forgeable
>    dead-tree silliness, but i'm happy to take equivalent formal and/or
>    archaic steps to smooth things out if other folks think they're
>    needed.

Alas, lawyers seems to prefer dead-tree silliness.

/Simon




From wk at gnupg.org  Tue Jun 17 21:18:24 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Jun 2008 21:18:24 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <87tzft2sgr.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 16 Jun 2008 19:35:32 +0200")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
	<c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
	<87y7555u6o.fsf@wheatstone.g10code.de>
	<87tzft2sgr.fsf@mocca.josefsson.org>
Message-ID: <874p7ryinz.fsf@wheatstone.g10code.de>

On Mon, 16 Jun 2008 19:35, simon at josefsson.org said:

> would be very cool.  Some alignment of the APIs here may be possible.
> Is GPGME under the LGPL so it can be used by libgnutls?

Yes.


Shalom-Salam,

   Werner

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





From wk at gnupg.org  Tue Jun 17 21:21:01 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Jun 2008 21:21:01 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <874p7tcb9i.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 17:36:57 -0400")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
	<87abhl895o.fsf@mocca.josefsson.org>
	<874p7tcb9i.fsf@squeak.fifthhorseman.net>
Message-ID: <87wsknx3z6.fsf@wheatstone.g10code.de>

On Mon, 16 Jun 2008 23:36, dkg at fifthhorseman.net said:

>    published electronic message carries more weight than any forgeable
>    dead-tree silliness, but i'm happy to take equivalent formal and/or
>    archaic steps to smooth things out if other folks think they're

Check out Bruce Schneier's latetest Cryptgram to see why paper and
pencil signatures have a lot of value.


Salam-Shalom,

   Werner

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





From simon at josefsson.org  Wed Jun 18 10:51:56 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jun 2008 10:51:56 +0200
Subject: OpenPGP certificate/key management thoughts about function
	re-organization and cleanup
In-Reply-To: <874p7ryinz.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Tue, 17 Jun 2008 21:18:24 +0200")
References: <87lk15ncpv.fsf@squeak.fifthhorseman.net>
	<87prqhzo9s.fsf@mocca.josefsson.org>
	<c331d99a0806160653o561e3579n2c2fdcb33d4486d@mail.gmail.com>
	<87y7555u6o.fsf@wheatstone.g10code.de>
	<87tzft2sgr.fsf@mocca.josefsson.org>
	<874p7ryinz.fsf@wheatstone.g10code.de>
Message-ID: <87skvbjfbn.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Mon, 16 Jun 2008 19:35, simon at josefsson.org said:
>
>> would be very cool.  Some alignment of the APIs here may be possible.
>> Is GPGME under the LGPL so it can be used by libgnutls?
>
> Yes.

Great.  Smoother integration between GPGME and gnutls's openpgp stuff
would be useful indeed, and seems feasible.  Alas, too little time.

Possibly it is simplest to do this using the sign callback interface in
GnuTLS.  The current callback API is a bit limited, and I don't know if
anyone is using it seriously, so it would need to be documented and
tested better.

/Simon




From simon at josefsson.org  Wed Jun 18 14:57:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jun 2008 14:57:07 +0200
Subject: openpgp fingerprints for subkeys
In-Reply-To: <87wskpihoo.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 16 Jun 2008 10:21:43 -0400")
References: <87prqim08q.fsf@squeak.fifthhorseman.net>
	<87tzftzot4.fsf@mocca.josefsson.org>
	<c331d99a0806160641v25828be7mef3e9122b5be31bd@mail.gmail.com>
	<87wskpihoo.fsf@squeak.fifthhorseman.net>
Message-ID: <87ve0652ak.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> Attached, please find a patch to provide this functionality.

Applied.

Thanks,
/Simon




From simon at josefsson.org  Wed Jun 18 17:56:22 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jun 2008 17:56:22 +0200
Subject: version 2.4.0 tagged and uploaded
Message-ID: <87r6au3ffd.fsf@mocca.josefsson.org>

FYI, I have tagged and uploaded the final 2.4.0 release.  There is now a
'gnutls_2_4_x' branch.  Windows and debian mingw32 packages are also
available, and I will test them on a separate machine.  You can help by
testing the packages early too, but the only possibility to fix things
at this point is to roll a 2.4.1 and announce that instead of 2.4.0.

ftp://ftp.gnu.org/gnu/gnutls/

/Simon




From simon at josefsson.org  Wed Jun 18 18:07:13 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jun 2008 18:07:13 +0200
Subject: 2.6.x goals?
Message-ID: <87prqe3exa.fsf@mocca.josefsson.org>

Nikos, what is the status of your mpi branch?  Is it ready for me to
review as if we would merge it into master?  Please hold off any merge
until I have reviewed and discussed the changes.

Btw, my goals for 2.5.x is to integrate Nikos' crypto.h stuff, and to
re-indent the code.  As far as I know, there are no other tasks that are
pending, or are there?  Anything major to be included should be made
available on a separate branch for review relatively soon, or it will
have to wait for 2.7.x.

All minor improvements like enhancing self-tests and fixing bugs should
be possible though, but they aren't release goals.  Waiting for
nice-things-to-have like better PKCS#11 integration, GPGME compatibility
etc will delay us, but people should feel free to start working on stuff
like that now anyway, 2.7.x isn't that far away.

Hopefully we can make the 2.5.x release cycle shorter than the last...
It would be nice to have a 2.6.x release candidate ready by August, to
get the crypto.h stuff out.

/Simon




From dkg-debian.org at fifthhorseman.net  Wed Jun 18 18:52:38 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Jun 2008 12:52:38 -0400
Subject: 2.6.x goals?
In-Reply-To: <87prqe3exa.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 18 Jun 2008 18\:07\:13 +0200")
References: <87prqe3exa.fsf@mocca.josefsson.org>
Message-ID: <87iqw6ofc9.fsf@squeak.fifthhorseman.net>

On Wed 2008-06-18 12:07:13 -0400, Simon Josefsson wrote:

> Btw, my goals for 2.5.x is to integrate Nikos' crypto.h stuff, and
> to re-indent the code.  As far as I know, there are no other tasks
> that are pending, or are there?  Anything major to be included
> should be made available on a separate branch for review relatively
> soon, or it will have to wait for 2.7.x.

I have three OpenPGP-related goals i'd like to see met for 2.6:

 * the ability to deal with passphrase-encrypted OpenPGP keys.

 * the ability to verify a specific UserID in an OpenPGP certificate
   without reference to any other UserIDs in the certificate.

 * the ability to create new OpenPGP keys (e.g. with certtool) and to
   add UserIDs and subkeys.

I don't know if these are already part of the MPI rewrite that you
mention: are the details for that documented someplace?

I'd be happy to contribute toward this as well, if i can find the time
and can figure it out.  I don't want to step on any toes, though, and
i don't want to create a lot of extra work if there are larger-scale
rewrites of the relevant sections going on concurrently.  Any thoughts
on how i should approach this?

I'd also be interested in developing the more-compact OpenPGP function
space that was just discussed on this list.  Guidance as to how to do
that cleanly would be appreciated.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080618/131cca6d/attachment.pgp>

From simon at josefsson.org  Wed Jun 18 22:57:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jun 2008 22:57:26 +0200
Subject: GnuTLS 2.3.15 - fourth and final (?) release	candidate for 2.4.0
In-Reply-To: <4859728C.30801@alice.it> (Massimo Gaspari's message of "Wed, 18
	Jun 2008 22:39:40 +0200")
References: <87abhm2wby.fsf@mocca.josefsson.org> <4859728C.30801@alice.it>
Message-ID: <87iqw6zcjt.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> I compiled the source with the following configuration
>
> libgpg-error 1.6 => ./configure --disable-shared --disable-rpath
> libgcrypt 1.4.1 => ./configure --disable-shared --enable-random=w32
> --disable-dev-random
> CFLAGS = -O2
> gnutls 2.3.15 => ./configure --disable-shared --disable-rpath
> --disable-cxx --disable-guile
> MinGW- Gcc 4.2.1 on Windows XP SP2
>
>
> I just got the following warnings
...
> The  "make test" ended successfully. No errors.

Thanks for the feedback.  Unfortunately it is too late to fix it for
v2.4.0, but I have fixed the warnings in the 2.5.x branch.

/Simon




From massimo.gaspari at alice.it  Wed Jun 18 22:39:40 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Wed, 18 Jun 2008 22:39:40 +0200
Subject: [Help-gnutls] GnuTLS 2.3.15 - fourth and final (?)
 release	candidate for 2.4.0
In-Reply-To: <87abhm2wby.fsf@mocca.josefsson.org>
References: <87abhm2wby.fsf@mocca.josefsson.org>
Message-ID: <4859728C.30801@alice.it>

Simon Josefsson wrote:
> Version 2.3.15 will hopefully be the final release candidate for the
> next stable release v2.4.0.  Please test v2.3.15 as if it were a stable
> release!  I'm cc'ing help-gnutls as well, to reach wider audience.
> Please report problems to gnutls-devel only.
>
> See below for the v2.4.0 release notes, comments and suggestions are
> welcome!
>
> This weekend is Midsommar in Sweden, and I'm leaving town on Thursday,
> thus expect the final 2.4.0 release on Thursday.
>
> Here are the compressed sources:
>   http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.15.tar.bz2
>   ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.15.tar.bz2
>
>   
I compiled the source with the following configuration

libgpg-error 1.6 => ./configure --disable-shared --disable-rpath
libgcrypt 1.4.1 => ./configure --disable-shared --enable-random=w32 
--disable-dev-random
CFLAGS = -O2
gnutls 2.3.15 => ./configure --disable-shared --disable-rpath 
--disable-cxx --disable-guile
MinGW- Gcc 4.2.1 on Windows XP SP2


I just got the following warnings

 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. 
-DLOCALEDIR=\"/usr/local/share/locale\"
 -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra 
-I../lib/o
penpgp/ -I/usr/local/include -I./opencdk -I../lib/opencdk -I./minitasn1 
-pipe -I
/usr/local/include -O2 -Wno-pointer-sign -MT gnutls_kx.lo -MD -MP -MF 
.deps/gnut
ls_kx.Tpo -c gnutls_kx.c -o gnutls_kx.o
gnutls_kx.c: In function '_gnutls_recv_server_kx_message':
gnutls_kx.c:392: warning: implicit declaration of function 
'_gnutls_session_is_psk'


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I
../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include -O2 
-Wno-pointer-sign
 -MT cli-gaa.o -MD -MP -MF .deps/cli-gaa.Tpo -c -o cli-gaa.o cli-gaa.c
 -MT cli-gaa.o -MD -MP -MF .deps/cli-gaa.Tpo -c -o cli-gaa.o cli-gaa.c
mv -f .deps/cli-gaa.Tpo .deps/cli-gaa.Po
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes 
-I../lgl -I
../lgl -I../gl -I../gl -I./cfg  -pipe -I/usr/local/include -O2 
-Wno-pointer-sign
 -MT cli.o -MD -MP -MF .deps/cli.Tpo -c -o cli.o cli.c
cli.c: In function 'psk_callback':
cli.c:996: warning: passing argument 2 of 'rpl_getline' from 
incompatible pointe
r type
cli.c:1015: warning: implicit declaration of function 'gnu_getpass'
cli.c:1015: warning: assignment makes pointer from integer without a cast


gcc -std=gnu99 -pipe -I/usr/local/include -O2 -Wno-pointer-sign -o 
gnutls-cli.ex
e cli-gaa.o cli.o common.o select.o  ../lib/.libs/libgnutls.a 
-L/usr/local/lib -
lz ../gl/.libs/libgnu.a /usr/local/lib/libgcrypt.a 
/usr/local/lib/libgpg-error.a
 -lws2_32 
 -MT psk-gaa.o -MD -MP -MF .deps/psk-gaa.Tpo -c -o psk-gaa.o psk-gaa.c
mv -f .deps/psk-gaa.Tpo .deps/psk-gaa.Po
 -MT psk.o -MD -MP -MF .deps/psk.Tpo -c -o psk.o psk.c
psk.c: In function 'main':
psk.c:141: warning: implicit declaration of function 'gnu_getpass'
psk.c:141: warning: assignment makes pointer from integer without a cast


The  "make test" ended successfully. No errors.

Hope this helps.

Max






From novel at FreeBSD.org  Thu Jun 19 07:03:10 2008
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Thu, 19 Jun 2008 09:03:10 +0400
Subject: building gnutls 2.3.15 with opencdk installed
Message-ID: <20080619050310.GA46818@underworld.novel.ru>

Hello,

I have a problem with building gnutls with having opencdk installed on
my system. I have opencdk 0.6.6 installed and when I try to build gnutls
I get the following error:

------------
 cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ -I/usr/local/include -I./opencdk -I../lib/opencdk -I./minitasn1 -I/usr/local/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -MT gnutls_openpgp.lo -MD -MP -MF .deps/gnutls_openpgp.Tpo -c gnutls_openpgp.c  -fPIC -DPIC -o .libs/gnutls_openpgp.o
gnutls_openpgp.c: In function `gnutls_openpgp_get_key':
gnutls_openpgp.c:219: error: syntax error before "st"
gnutls_openpgp.c:242: error: `st' undeclared (first use in this function)
gnutls_openpgp.c:242: error: (Each undeclared identifier is reported only once
gnutls_openpgp.c:242: error: for each function it appears in.)
gnutls_openpgp.c:242: warning: passing arg 2 of `cdk_keydb_search_start' makes integer from pointer without a cast
gnutls_openpgp.c:242: error: incompatible type for argument 3 of `cdk_keydb_search_start'
gnutls_openpgp.c:242: error: too many arguments to function `cdk_keydb_search_start'
gnutls_openpgp.c:244: warning: passing arg 2 of `cdk_keydb_search' from incompatible pointer type
gnutls_openpgp.c:244: error: too many arguments to function `cdk_keydb_search'
gnutls_openpgp.c:246: warning: implicit declaration of function `cdk_keydb_search_release'
gmake[3]: *** [gnutls_openpgp.lo] Error 1
gmake[3]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15/lib'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15'
gmake: *** [all] Error 2
*** Error code 2
-----------

It seem to happen because it picks opencdk.h from the installed opencdk version, 
not from the included one. When I deinstall opencdk from my system,
gnutls compiles fine.

Is there any way to workaround this?

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

From n.mavrogiannopoulos at gmail.com  Thu Jun 19 11:14:39 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 19 Jun 2008 12:14:39 +0300
Subject: 2.6.x goals?
In-Reply-To: <87prqe3exa.fsf@mocca.josefsson.org>
References: <87prqe3exa.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0806190214x6047cc88ufac83118d33257ea@mail.gmail.com>

On Wed, Jun 18, 2008 at 7:07 PM, Simon Josefsson <simon at josefsson.org> wrote:
> Nikos, what is the status of your mpi branch?  Is it ready for me to
> review as if we would merge it into master?  Please hold off any merge
> until I have reviewed and discussed the changes.

It is complete except for some parts of opencdk.




From simon at josefsson.org  Thu Jun 19 11:18:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 11:18:38 +0200
Subject: GnuTLS 2.4.0
Message-ID: <87r6atn5ox.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.4.0.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains TLS/IA support, LZO compression -- and the
OpenSSL compatibility library self tests and command line tools are
distributed under the GNU General Public License version 3.0 (or later).
The manual is distributed under the GNU Free Documentation License
version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/

What's New
==========

Major end-user visible changes compared to the v2.2 branch:

* The OpenPGP sub-system has been improved and now supports subkeys.

* The PSK sub-system has been improved and now supports password
  derivation and PSK identity hints.

  The password derivation algorithms support is documented in
  draft-ietf-netconf-tls-02.txt.

* The certtool --inder and --outder has been replaced by --inraw and --outraw.

  This aligns terminology with OpenPGP, which doesn't use DER
  encoding.  The old parameters will continue to work for some time.

* Certtool now confirm passwords and changes permissions of private key files.

* The default handshake size limit has been increased to 48kb.

  It appears as if some valid handshakes are large due to sending many
  CA certificates.  (The earlier limit was 16kb.)

* LZO compression is now disabled by default.

  The main reason is that LZO compression in TLS is not standardized,
  but license compatiblity issues with minilzo triggered us to make
  this decision now.

* Improvements for cross-compilation to Windows and OpenWRT.

* The look of the GTK-DOC manual has been improved.

Major developer visible changes compared to the v2.2 branch:

* Full OpenPGP support is part of libgnutls, licensed under the LGPL.

* New APIs to access the raw X.509 Subject and Issuer DN's and
  elements from the certificate credentials structure, thanks to Joe
  Orton.

* New APIs to improve working with username/passwords and PSK.

* Names of constants to affect certificate printing changed.

  The constants are used for OpenPGP too, which the names didn't
  reflect, so the following name change has been made:

            Old name                         New name
     GNUTLS_X509_CRT_FULL            GNUTLS_CRT_PRINT_FULL
     GNUTLS_X509_CRT_ONELINE         GNUTLS_CRT_PRINT_ONELINE
     GNUTLS_X509_CRT_UNSIGNED_FULL   GNUTLS_CRT_PRINT_UNSIGNED_FULL

  The old names will be mapped to the new names for some time.

* The function gnutls_openpgp_privkey_get_id has been renamed to
  gnutls_openpgp_privkey_get_key_id.

  A compatibility mapping exists to avoid breaking API backwards
  compatibility.

* Replaced all uses of alloca with malloc and free.

* We no longer build with -D_REENTRANT -D_THREAD_SAFE.

  We have been unable to find a documented rationale for this
  practice.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.4
=============================

All OpenPGP related functions have been moved from libgnutls-extra to
libgnutls, and several new functions have been added (see below).
Before making the release, we discussed whether moving functions from
libgnutls-extra to libgnutls would require us to increment the ABI
version, but the general opinion was that this would not be required.
All older functions continue to work the same.  We are open to the
possibility that this decision will lead to problem on some platform,
and if it turns out that the Right Thing should have been to increment
the shared library version, we would need to release an update within
the 2.4.x branch that increments the shared library version.

This release adds the following functions:

  gnutls_psk_client_get_hint
  gnutls_psk_set_server_credentials_hint
  gnutls_psk_netconf_derive_key

    Used to get/set the PSK identity hint, and derive PSK keys from
    passwords a'la netconf.

  gnutls_x509_dn_deinit
  gnutls_x509_dn_export
  gnutls_x509_dn_import
  gnutls_x509_dn_init

    Used to handle X.509 Certificate DN's directly.

  gnutls_hex2bin

    Converts a data buffer to hex.  Useful for handling PSK/SRP shared
    secrets.

  gnutls_certificate_get_x509_cas
  gnutls_certificate_get_x509_crls
  gnutls_certificate_get_openpgp_keyring

    Functions for direct access to credential elements.

  gnutls_openpgp_crt_get_auth_subkey
  gnutls_openpgp_crt_get_key_id
  gnutls_openpgp_crt_get_pk_dsa_raw
  gnutls_openpgp_crt_get_pk_rsa_raw
  gnutls_openpgp_crt_get_preferred_key_id
  gnutls_openpgp_crt_get_revoked_status
  gnutls_openpgp_crt_get_subkey_count
  gnutls_openpgp_crt_get_subkey_creation_time
  gnutls_openpgp_crt_get_subkey_expiration_time
  gnutls_openpgp_crt_get_subkey_fingerprint
  gnutls_openpgp_crt_get_subkey_id
  gnutls_openpgp_crt_get_subkey_idx
  gnutls_openpgp_crt_get_subkey_pk_algorithm
  gnutls_openpgp_crt_get_subkey_pk_dsa_raw
  gnutls_openpgp_crt_get_subkey_pk_rsa_raw
  gnutls_openpgp_crt_get_subkey_revoked_status
  gnutls_openpgp_crt_get_subkey_usage
  gnutls_openpgp_crt_print
  gnutls_openpgp_crt_set_preferred_key_id
  gnutls_openpgp_keyring_get_crt
  gnutls_openpgp_keyring_get_crt_count
  gnutls_openpgp_privkey_export
  gnutls_openpgp_privkey_export_dsa_raw
  gnutls_openpgp_privkey_export_rsa_raw
  gnutls_openpgp_privkey_export_subkey_dsa_raw
  gnutls_openpgp_privkey_export_subkey_rsa_raw
  gnutls_openpgp_privkey_get_fingerprint
  gnutls_openpgp_privkey_get_key_id
  gnutls_openpgp_privkey_get_pk_algorithm
  gnutls_openpgp_privkey_get_preferred_key_id
  gnutls_openpgp_privkey_get_revoked_status
  gnutls_openpgp_privkey_get_subkey_count
  gnutls_openpgp_privkey_get_subkey_creation_time
  gnutls_openpgp_privkey_get_subkey_expiration_time
  gnutls_openpgp_privkey_get_subkey_fingerprint
  gnutls_openpgp_privkey_get_subkey_id
  gnutls_openpgp_privkey_get_subkey_idx
  gnutls_openpgp_privkey_get_subkey_pk_algorithm
  gnutls_openpgp_privkey_get_subkey_revoked_status
  gnutls_openpgp_privkey_set_preferred_key_id

    New OpenPGP related functions.

    The function gnutls_openpgp_crt_get_key_id is the same as the old
    from gnutls_openpgp_crt_get_id, see above.

The release also adds a new header file 'gnutls/crypto.h', however it
is currently not used.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.  Note, that GnuPG is
not available at ftp.gnu.org.

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.0.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.4.0.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.0.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.4.0.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.4.0.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

9bb3be9f2ad67037d3a571bec4fac65e0ffbadbb  gnutls-2.4.0.tar.bz2

9dc4435b637a4841a88ec294b8a82841eb257cee4948bc957c1a96d7  gnutls-2.4.0.tar.bz2

Documentation
=============

The manual is available online at:

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

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:
<http://lists.gnupg.org/mailman/listinfo/gnutls-dev>.

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.4.0.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.4.0.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.4.0.exe.sig

The checksum values for SHA-1 and SHA-224 are:

e704df715ed6cad14c7a6e4350d7557d81de655b  gnutls-2.4.0.exe

b548c3178f89669d1245b266c7caa834feeea63b142a8871f1185097  gnutls-2.4.0.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

3fc1e58fe58ac77c6dc433052685d59400a88559  mingw32-gnutls_2.4.0-1_all.deb

601549a449ce25dc4520c591bad42d833b23f05a8f67cf4fe732f7de  mingw32-gnutls_2.4.0-1_all.deb

Internationalization
====================

GnuTLS messages have been translated into Dutch, German, Malay, Polish,
Swedish, and Vietnamese.  We welcome the addition of more translations.

Support
=======

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.

The GnuTLS service directory is available at:

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

Happy Hacking,
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/20080619/ce15cda6/attachment.pgp>

From simon at josefsson.org  Thu Jun 19 11:26:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 11:26:50 +0200
Subject: 2.6.x goals?
In-Reply-To: <c331d99a0806190214x6047cc88ufac83118d33257ea@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 19 Jun 2008 12:14:39
	+0300")
References: <87prqe3exa.fsf@mocca.josefsson.org>
	<c331d99a0806190214x6047cc88ufac83118d33257ea@mail.gmail.com>
Message-ID: <87mylhn5b9.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Wed, Jun 18, 2008 at 7:07 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> Nikos, what is the status of your mpi branch?  Is it ready for me to
>> review as if we would merge it into master?  Please hold off any merge
>> until I have reviewed and discussed the changes.
>
> It is complete except for some parts of opencdk.

Great.  Do you want to run 'git-merge master' in your branch to sync it
up to master, or should I do it?  After that, we can test it and see if
it is ready to merge onto master.

/Simon




From simon at josefsson.org  Thu Jun 19 11:35:36 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 11:35:36 +0200
Subject: building gnutls 2.3.15 with opencdk installed
In-Reply-To: <20080619050310.GA46818@underworld.novel.ru> (Roman Bogorodskiy's
	message of "Thu, 19 Jun 2008 09:03:10 +0400")
References: <20080619050310.GA46818@underworld.novel.ru>
Message-ID: <87iqw5n4wn.fsf@mocca.josefsson.org>

Roman Bogorodskiy <novel at FreeBSD.org> writes:

> Hello,
>
> I have a problem with building gnutls with having opencdk installed on
> my system. I have opencdk 0.6.6 installed and when I try to build gnutls
> I get the following error:
>
> ------------
>  cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ -I/usr/local/include -I./opencdk -I../lib/opencdk -I./minitasn1 -I/usr/local/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -MT gnutls_openpgp.lo -MD -MP -MF .deps/gnutls_openpgp.Tpo -c gnutls_openpgp.c  -fPIC -DPIC -o .libs/gnutls_openpgp.o
> gnutls_openpgp.c: In function `gnutls_openpgp_get_key':
> gnutls_openpgp.c:219: error: syntax error before "st"
> gnutls_openpgp.c:242: error: `st' undeclared (first use in this function)
> gnutls_openpgp.c:242: error: (Each undeclared identifier is reported only once
> gnutls_openpgp.c:242: error: for each function it appears in.)
> gnutls_openpgp.c:242: warning: passing arg 2 of `cdk_keydb_search_start' makes integer from pointer without a cast
> gnutls_openpgp.c:242: error: incompatible type for argument 3 of `cdk_keydb_search_start'
> gnutls_openpgp.c:242: error: too many arguments to function `cdk_keydb_search_start'
> gnutls_openpgp.c:244: warning: passing arg 2 of `cdk_keydb_search' from incompatible pointer type
> gnutls_openpgp.c:244: error: too many arguments to function `cdk_keydb_search'
> gnutls_openpgp.c:246: warning: implicit declaration of function `cdk_keydb_search_release'
> gmake[3]: *** [gnutls_openpgp.lo] Error 1
> gmake[3]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15/lib'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15/lib'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/usr/home/novel/ports_stuff/gnutls-devel/work/gnutls-2.3.15'
> gmake: *** [all] Error 2
> *** Error code 2
> -----------
>
> It seem to happen because it picks opencdk.h from the installed opencdk version, 
> not from the included one. When I deinstall opencdk from my system,
> gnutls compiles fine.
>
> Is there any way to workaround this?

Hi!  Strange, I don't get this and I also have opencdk 0.6.6 installed.
Is there anything uncommon in how you build this?  Why doesn't it prefer
the opencdk.h from the -I's listed on your command line?  The opencdk.h
file in gnutls should be in one of those directories, and the -I's
appear to be earlier than any system -I's.

/Simon




From dragonheart at gentoo.org  Thu Jun 19 11:14:29 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Thu, 19 Jun 2008 19:14:29 +1000
Subject: 2.3.15 patches - QA includes to fix compile warnings
Message-ID: <200806191914.34879.dragonheart@gentoo.org>


2.3.11+gcc-4.3 patch thanks to 01 Jun 2008; Diego Petten?? 
<flameeyes at gentoo.org>
https://bugs.gentoo.org/show_bug.cgi?id=224453


gnutls-2.3.15-qa_gnutls_session_is_psk.patch is mine and fixes 
gnutls_kx.c:392: warning: implicit declaration of 
function '_gnutls_session_is_psk'

-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.3.15-qa_gnutls_session_is_psk.patch
Type: text/x-diff
Size: 394 bytes
Desc: not available
URL: </pipermail/attachments/20080619/00351f76/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.3.11+gcc-4.3.patch
Type: text/x-diff
Size: 349 bytes
Desc: not available
URL: </pipermail/attachments/20080619/00351f76/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080619/00351f76/attachment.pgp>

From dragonheart at gentoo.org  Thu Jun 19 11:29:35 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Thu, 19 Jun 2008 19:29:35 +1000
Subject: 2.3.15 patches - QA includes to fix compile warnings
In-Reply-To: <200806191914.34879.dragonheart@gentoo.org>
References: <200806191914.34879.dragonheart@gentoo.org>
Message-ID: <200806191929.35524.dragonheart@gentoo.org>

On Thu, 19 Jun 2008 07:14:29 pm Daniel Black wrote:
> 2.3.11+gcc-4.3 patch thanks to 01 Jun 2008; Diego Petten??
> <flameeyes at gentoo.org>
> https://bugs.gentoo.org/show_bug.cgi?id=224453
>
>
> gnutls-2.3.15-qa_gnutls_session_is_psk.patch is mine and fixes
> gnutls_kx.c:392: warning: implicit declaration of
> function '_gnutls_session_is_psk'

both still missing from 2.4.0 now that i've found it.

forgot to mention I couldn't find a development snapshot branch for 2.3 /2.4 
if you plan on making one.

-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080619/174420a1/attachment.pgp>

From simon at josefsson.org  Thu Jun 19 12:37:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 12:37:17 +0200
Subject: GnuTLS 2.3.15 - fourth and final (?) release	candidate for 2.4.0
In-Reply-To: <87iqw6zcjt.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 18 Jun 2008 22:57:26 +0200")
References: <87abhm2wby.fsf@mocca.josefsson.org> <4859728C.30801@alice.it>
	<87iqw6zcjt.fsf@mocca.josefsson.org>
Message-ID: <87abhhn21u.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Massimo Gaspari <massimo.gaspari at alice.it> writes:
>
>> I compiled the source with the following configuration
>>
>> libgpg-error 1.6 => ./configure --disable-shared --disable-rpath
>> libgcrypt 1.4.1 => ./configure --disable-shared --enable-random=w32
>> --disable-dev-random
>> CFLAGS = -O2
>> gnutls 2.3.15 => ./configure --disable-shared --disable-rpath
>> --disable-cxx --disable-guile
>> MinGW- Gcc 4.2.1 on Windows XP SP2
>>
>>
>> I just got the following warnings
> ...
>> The  "make test" ended successfully. No errors.
>
> Thanks for the feedback.  Unfortunately it is too late to fix it for
> v2.4.0, but I have fixed the warnings in the 2.5.x branch.

I've back-ported these fixes to the 2.4.x branch as well.

/Simon




From simon at josefsson.org  Thu Jun 19 12:39:40 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 12:39:40 +0200
Subject: 2.3.15 patches - QA includes to fix compile warnings
In-Reply-To: <200806191914.34879.dragonheart@gentoo.org> (Daniel Black's
	message of "Thu, 19 Jun 2008 19:14:29 +1000")
References: <200806191914.34879.dragonheart@gentoo.org>
Message-ID: <8763s5n1xv.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> 2.3.11+gcc-4.3 patch thanks to 01 Jun 2008; Diego Petten?? 
> <flameeyes at gentoo.org>
> https://bugs.gentoo.org/show_bug.cgi?id=224453
>
> Index: gnutls-2.3.11/doc/examples/ex-cxx.cpp
> ===================================================================
> --- gnutls-2.3.11.orig/doc/examples/ex-cxx.cpp
> +++ gnutls-2.3.11/doc/examples/ex-cxx.cpp
> @@ -4,6 +4,7 @@
>  #endif
>  #include <iostream>
>  #include <stdexcept>
> +#include <cstring>
>  #include <gnutls/gnutls.h>
>  #include <gnutls/gnutlsxx.h>

We solved this earlier by adding the following instead:

#include <string.h> /* for strlen */

That should be in 2.4.x too.  Is it better to use <cstring>?  I don't
know.

> gnutls-2.3.15-qa_gnutls_session_is_psk.patch is mine and fixes 
> gnutls_kx.c:392: warning: implicit declaration of 
> function '_gnutls_session_is_psk'
>
> --- ./lib/gnutls_state.h.orig	2008-06-19 18:54:50.000000000 +1000
> +++ ./lib/gnutls_state.h	2008-06-19 18:55:57.000000000 +1000
> @@ -58,6 +58,7 @@
>  
>  int _gnutls_session_is_resumable (gnutls_session_t session);
>  int _gnutls_session_is_export (gnutls_session_t session);
> +int _gnutls_session_is_psk (gnutls_session_t session);
>  
>  int _gnutls_openpgp_send_fingerprint (gnutls_session_t session);

This has been fixed already, but didn't make it for 2.4.0.

Thanks,
/Simon




From simon at josefsson.org  Thu Jun 19 12:40:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 12:40:27 +0200
Subject: 2.3.15 patches - QA includes to fix compile warnings
In-Reply-To: <200806191929.35524.dragonheart@gentoo.org> (Daniel Black's
	message of "Thu, 19 Jun 2008 19:29:35 +1000")
References: <200806191914.34879.dragonheart@gentoo.org>
	<200806191929.35524.dragonheart@gentoo.org>
Message-ID: <871w2tn1wk.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> forgot to mention I couldn't find a development snapshot branch for 2.3 /2.4 
> if you plan on making one.

For some reason the daily auto-builder cannot build gnutls 2.3/2.4 due
to a strange TeX/Texinfo error.  I'll see if I can fix it.

/Simon




From dragonheart at gentoo.org  Thu Jun 19 12:54:12 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Thu, 19 Jun 2008 20:54:12 +1000
Subject: 2.3.15 patches - QA includes to fix compile warnings
In-Reply-To: <8763s5n1xv.fsf@mocca.josefsson.org>
References: <200806191914.34879.dragonheart@gentoo.org>
	<8763s5n1xv.fsf@mocca.josefsson.org>
Message-ID: <200806192054.20706.dragonheart@gentoo.org>

On Thu, 19 Jun 2008 08:39:40 pm Simon Josefsson wrote:
> Daniel Black <dragonheart at gentoo.org> writes:
> > 2.3.11+gcc-4.3 patch thanks to 01 Jun 2008; Diego Petten??
> > <flameeyes at gentoo.org>
> > https://bugs.gentoo.org/show_bug.cgi?id=224453
> >
> > Index: gnutls-2.3.11/doc/examples/ex-cxx.cpp
> > ===================================================================
> > --- gnutls-2.3.11.orig/doc/examples/ex-cxx.cpp
> > +++ gnutls-2.3.11/doc/examples/ex-cxx.cpp
> > @@ -4,6 +4,7 @@
> >  #endif
> >  #include <iostream>
> >  #include <stdexcept>
> > +#include <cstring>
> >  #include <gnutls/gnutls.h>
> >  #include <gnutls/gnutlsxx.h>
>
> We solved this earlier by adding the following instead:
>
> #include <string.h> /* for strlen */
>
> That should be in 2.4.x too.  Is it better to use <cstring>?

cstring is more c++ like. probably handles unicode and stuff better. not sure 
if thats in this example.

> I don't know.

i trust Diego on this because i'm not sure either.

>
> > gnutls-2.3.15-qa_gnutls_session_is_psk.patch is mine and fixes
>
> This has been fixed already, but didn't make it for 2.4.0.

ok thanks.

>
> Thanks,
> /Simon



-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080619/5557c4d2/attachment.pgp>

From simon at josefsson.org  Thu Jun 19 13:18:52 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 13:18:52 +0200
Subject: 2.3.15 patches - QA includes to fix compile warnings
In-Reply-To: <200806192054.20706.dragonheart@gentoo.org> (Daniel Black's
	message of "Thu, 19 Jun 2008 20:54:12 +1000")
References: <200806191914.34879.dragonheart@gentoo.org>
	<8763s5n1xv.fsf@mocca.josefsson.org>
	<200806192054.20706.dragonheart@gentoo.org>
Message-ID: <87k5glllk3.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> On Thu, 19 Jun 2008 08:39:40 pm Simon Josefsson wrote:
>> Daniel Black <dragonheart at gentoo.org> writes:
>> > 2.3.11+gcc-4.3 patch thanks to 01 Jun 2008; Diego Petten??
>> > <flameeyes at gentoo.org>
>> > https://bugs.gentoo.org/show_bug.cgi?id=224453
>> >
>> > Index: gnutls-2.3.11/doc/examples/ex-cxx.cpp
>> > ===================================================================
>> > --- gnutls-2.3.11.orig/doc/examples/ex-cxx.cpp
>> > +++ gnutls-2.3.11/doc/examples/ex-cxx.cpp
>> > @@ -4,6 +4,7 @@
>> >  #endif
>> >  #include <iostream>
>> >  #include <stdexcept>
>> > +#include <cstring>
>> >  #include <gnutls/gnutls.h>
>> >  #include <gnutls/gnutlsxx.h>
>>
>> We solved this earlier by adding the following instead:
>>
>> #include <string.h> /* for strlen */
>>
>> That should be in 2.4.x too.  Is it better to use <cstring>?
>
> cstring is more c++ like. probably handles unicode and stuff better. not sure 
> if thats in this example.
>
>> I don't know.
>
> i trust Diego on this because i'm not sure either.

I searched a bit, and cstring seems better than string.h, so I made the
change in the 2.5.x branch.  I won't backport to 2.4.x unless there are
reports that using string.h causes compilation failure on some platform.

Thanks,
/Simon




From novel at FreeBSD.org  Thu Jun 19 13:38:46 2008
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Thu, 19 Jun 2008 15:38:46 +0400
Subject: building gnutls 2.3.15 with opencdk installed
In-Reply-To: <87iqw5n4wn.fsf@mocca.josefsson.org>
References: <20080619050310.GA46818@underworld.novel.ru>
	<87iqw5n4wn.fsf@mocca.josefsson.org>
Message-ID: <20080619113846.GA1967@underworld.novel.ru>

  Simon Josefsson wrote:

> 
> > ------------
> >  cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ -I/usr/local/include -I./opencdk -I../lib/opencdk -I./minitasn1 -I/usr/local/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -MT gnutls_openpgp.lo -MD -MP -MF .deps/gnutls_openpgp.Tpo -c gnutls_openpgp.c  -fPIC -DPIC -o .libs/gnutls_openpgp.o

<--->
> 
> Hi!  Strange, I don't get this and I also have opencdk 0.6.6 installed.
> Is there anything uncommon in how you build this?  Why doesn't it prefer
> the opencdk.h from the -I's listed on your command line?  The opencdk.h
> file in gnutls should be in one of those directories, and the -I's
> appear to be earlier than any system -I's.

Well, '-I/usr/local/include' appears before ' -I./opencdk
-I../lib/opencdk', that's why it picks wrong opencdk.h I think.

lib/Makefile.am has the following code:

-----------------
AM_CPPFLAGS = -DLOCALEDIR=\"$(localedir)\"                              \
        -I$(top_srcdir)/lgl -I$(top_builddir)/lgl                       \
        -I$(top_srcdir)/includes -I../includes                          \
        -I$(srcdir)/x509                                                \
        -I$(top_srcdir)/libextra -I$(top_srcdir)/lib/openpgp/   \
        $(LIBGCRYPT_CFLAGS)

if ENABLE_OPENPGP
SUBDIRS += opencdk
SUBDIRS += openpgp
AM_CPPFLAGS += -I$(srcdir)/opencdk -I$(top_srcdir)/lib/opencdk
endif
-----------------

I guess "-I/usr/local/include" appears here in place of $(LIBGCRYPT_CFLAGS). So the 
problem probably could be fixed by changing -I flags order in
AM_CPPFLAGS, i.e. placing opencdk stuff before $(LIBGCRYPT_CFLAGS). But
I'm not sure, I cannot test it at this moment, will be able to check a
bit later. 

> /Simon
> 
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel

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

From simon at josefsson.org  Thu Jun 19 14:28:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jun 2008 14:28:27 +0200
Subject: 2.6.x goals?
In-Reply-To: <87iqw6ofc9.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Wed, 18 Jun 2008 12:52:38 -0400")
References: <87prqe3exa.fsf@mocca.josefsson.org>
	<87iqw6ofc9.fsf@squeak.fifthhorseman.net>
Message-ID: <87abhhlic4.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Wed 2008-06-18 12:07:13 -0400, Simon Josefsson wrote:
>
>> Btw, my goals for 2.5.x is to integrate Nikos' crypto.h stuff, and
>> to re-indent the code.  As far as I know, there are no other tasks
>> that are pending, or are there?  Anything major to be included
>> should be made available on a separate branch for review relatively
>> soon, or it will have to wait for 2.7.x.
>
> I have three OpenPGP-related goals i'd like to see met for 2.6:
>
>  * the ability to deal with passphrase-encrypted OpenPGP keys.
>
>  * the ability to verify a specific UserID in an OpenPGP certificate
>    without reference to any other UserIDs in the certificate.
>
>  * the ability to create new OpenPGP keys (e.g. with certtool) and to
>    add UserIDs and subkeys.

Sounds fine to me.

> I don't know if these are already part of the MPI rewrite that you
> mention: are the details for that documented someplace?

Nope, the MPI stuff is the gnutls_with_ext_mpi branch:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=shortlog;h=refs/heads/gnutls_with_ext_mpi

It allows modular replacement of libgcrypt.

> I'd be happy to contribute toward this as well, if i can find the time
> and can figure it out.  I don't want to step on any toes, though, and
> i don't want to create a lot of extra work if there are larger-scale
> rewrites of the relevant sections going on concurrently.  Any thoughts
> on how i should approach this?

The best way to get started is to create a branch and add your functions
to that branch and ask me to merge it when you think it is stable.  I'm
not aware of anything large-scale work being done in this area.  The
only one doing major work on the OpenPGP stuff is Nikos, so he can tell
for sure.

All development discussion happens on this list, so if there is nothing
on a particular topic here it means nobody has done anything beyond
possibly thinking about it.

> I'd also be interested in developing the more-compact OpenPGP function
> space that was just discussed on this list.  Guidance as to how to do
> that cleanly would be appreciated.

I think the simplest would be if you propose the API you are thinking
of, and ask whether people like it better.  It may be useful for you to
review the GPGME stuff and decide whether you think it is possible to do
closer integration or compatibility with it or not.  Nikos may want to
chime in here too.

/Simon




From mrsam at courier-mta.com  Mon Jun 23 00:28:50 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 22 Jun 2008 18:28:50 -0400
Subject: PEM generated by gnutls_rsa_params_export_pkcs1 and
 gnutls_dh_params_import_pkcs3
Message-ID: <cone.1214173730.370910.24152.500@commodore.email-scan.com>

The buffer size return value from gnutls_dh_params_import_pkcs3(), when 
specifying GNUTLS_X509_FMT_PEM, seems to include a trailing \0 byte, after 
"-----END DH PARAMETERS-----<NL>". On the other hand, 
gnutls_rsa_params_export_pkcs1() with GNUTLS_X509_FMT_PEM sets the returned 
buffer size to not include any trailing \0, after "-----END RSA PRIVATE 
KEY-----<NL>".

That's the behavior I've observed with 2.0.4; and I haven't yet built 2.4.0. 
If that's the case, I'm not really sure if it's a major issue, but perhaps 
this should be noted in the man pages.

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

From nmav at gnutls.org  Mon Jun 23 01:24:40 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 23 Jun 2008 02:24:40 +0300
Subject: PEM generated by gnutls_rsa_params_export_pkcs1 and
	gnutls_dh_params_import_pkcs3
In-Reply-To: <cone.1214173730.370910.24152.500@commodore.email-scan.com>
References: <cone.1214173730.370910.24152.500@commodore.email-scan.com>
Message-ID: <485EDF38.304@gnutls.org>

Sam Varshavchik wrote:
> The buffer size return value from gnutls_dh_params_import_pkcs3(), when
> specifying GNUTLS_X509_FMT_PEM, seems to include a trailing \0 byte,
> after "-----END DH PARAMETERS-----<NL>". On the other hand,
> gnutls_rsa_params_export_pkcs1() with GNUTLS_X509_FMT_PEM sets the
> returned buffer size to not include any trailing \0, after "-----END RSA
> PRIVATE KEY-----<NL>".
> 
> That's the behavior I've observed with 2.0.4; and I haven't yet built
> 2.4.0. If that's the case, I'm not really sure if it's a major issue,
> but perhaps this should be noted in the man pages.

Hello,
 This is a bug for sure, thank you for reporting it. Does the attached
patch solve your issue?

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: </pipermail/attachments/20080623/a2171154/attachment.txt>

From mrsam at courier-mta.com  Mon Jun 23 02:25:44 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 22 Jun 2008 20:25:44 -0400
Subject: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)
Message-ID: <cone.1214180744.503610.26499.500@commodore.email-scan.com>

I'm chasing a complaint from valgrind that I'm leaking memory.

Here's valgrind's complaint:

==26738== 257 bytes in 1 blocks are definitely lost in loss record 2 of 4
==26738==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==26738==    by 0x35068328F6: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
==26738==    by 0x350683E47C: _gnutls_dh_set_peer_public (gnutls_state.c:474)
==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx (auth_dh_common.c:297)
==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message (gnutls_kx.c:339)
==26738==    by 0x35068273DF: _gnutls_handshake_client (gnutls_handshake.c:2311)
==26738==    by 0x3506827F77: gnutls_handshake (gnutls_handshake.c:2193)


Here's what I've been able to figure out. I'm running gnutls 2.0.4, but I 
checked 2.4.0, and the affected bits have not changed, the following should 
still be applicable.

_gnutls_mpi_dprint_lz() allocates a buffer:

  if (bytes != 0)
    buf = gnutls_malloc (bytes);

. . . and puts it into its gnutls_datum_t parameter:

  if (!ret)
    {
      dest->data = buf;
      dest->size = bytes;
      return 0;
    }


If I set a breakpoint in _gnutls_dh_set_peer_public(), then I find that this 
breakpoint gets hit twice from gnutls_handshake():

#0  _gnutls_dh_set_peer_public (session=0x144fcc0, public=0x1431a70)
    at gnutls_state.c:474
#1  0x000000350684381a in _gnutls_proc_dh_common_server_kx (
    session=<value optimized out>, data=<value optimized out>, 
    _data_size=<value optimized out>, psk=<value optimized out>)
    at auth_dh_common.c:297
#2  0x000000350683bb50 in proc_dhe_server_kx (session=<value optimized out>, 
    data=<value optimized out>, _data_size=<value optimized out>)
    at auth_dhe.c:199
#3  0x000000350682af82 in _gnutls_recv_server_kx_message (
    session=<value optimized out>) at gnutls_kx.c:339
#4  0x00000035068273e0 in _gnutls_handshake_client (
    session=<value optimized out>) at gnutls_handshake.c:2311
#5  0x0000003506827f78 in gnutls_handshake (session=<value optimized out>)
    at gnutls_handshake.c:2193

Second breakpoint hit:

#0  _gnutls_dh_set_peer_public (session=0x144fcc0, public=0x1431a70)
    at gnutls_state.c:474
#1  0x0000003506843b8f in _gnutls_gen_dh_common_client_kx (
    session=<value optimized out>, data=<value optimized out>)
    at auth_dh_common.c:167
#2  0x000000350682aac1 in _gnutls_send_client_kx_message (
    session=<value optimized out>, again=<value optimized out>)
    at gnutls_kx.c:231
#3  0x000000350682736d in _gnutls_handshake_client (
    session=<value optimized out>) at gnutls_handshake.c:2352
#4  0x0000003506827f78 in gnutls_handshake (session=<value optimized out>)
    at gnutls_handshake.c:2193

Observe that _gnutls_dh_set_peer_public() invokes _gnutls_mpi_dprint_lz(), 
passing it the address of _gnutls_get_auth_info(session)->dh.public_key.

I hit the breakpoint the first time:

(gdb) p dh
$20 = (dh_info_st *) 0x8da8f8
(gdb) p $20->public_key
$21 = {data = 0x0, size = 0}

Empty unallocated buffer. Let me step into and out of the 
_gnutls_mpi_dprint_lz() function call:

(gdb) s
_gnutls_mpi_dprint_lz (dest=<value optimized out>, a=<value optimized out>)
    at gnutls_mpi.c:135
135	{
(gdb) finish
Run till exit from #0  _gnutls_mpi_dprint_lz (dest=<value optimized out>, 
    a=<value optimized out>) at gnutls_mpi.c:135
_gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:475
475	  if (ret < 0)
Value returned is $22 = 0
(gdb) p $20->public_key
$23 = {data = 0x8e2cd0 "", size = 257}

_gnutls_mpi_dprint_lz() does its thing, and returns, leaving the public_key 
datum allocated. Fine.

I'm going to let it run now, and let it hit the breakpoint the 2nd time:

(gdb) c
Continuing.

Breakpoint 3, _gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:474
474	  ret = _gnutls_mpi_dprint_lz (&dh?public_key, public);
(gdb) p dh
$24 = (dh_info_st *) 0x8da8f8
(gdb) p $24->public_key
$25 = {data = 0x8e2cd0 "", size = 257}

The buffer is still there, where it was before. Now you can see what's going 
to happen:

(gdb) s
_gnutls_mpi_dprint_lz (dest=<value optimized out>, a=<value optimized out>)
    at gnutls_mpi.c:135
135	{
(gdb) finish
Run till exit from #0  _gnutls_mpi_dprint_lz (dest=<value optimized out>, 
    a=<value optimized out>) at gnutls_mpi.c:135
_gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:475
475	  if (ret < 0)
Value returned is $26 = 0
(gdb) p $24->public_key
$27 = {data = 0x8e7460 "", size = 257}

_gnutls_mpi_dprint_lz() did not check that its datum parameter was already 
initialized with a memory chunk, and allocated another memory block, 
overwriting the pointer, and leaking that memory block.

I cannot say what's the correct fix: have _gnutls_mpi_dprint_lz() clean up 
its gnutls_datum_t parameter, if it already points to some other memory 
chunk, or have _gnutls_dh_set_peer_public() check if dh->public_key is 
already initialized, and avoid calling _gnutls_mpi_dprint_lz() if so.

I also see the same logic in _gnutls_mpi_dprint() as well, there's a good 
possibility that there are execution paths that might trigger a leak there 
as well.

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

From mrsam at courier-mta.com  Mon Jun 23 03:28:08 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 22 Jun 2008 21:28:08 -0400
Subject: PEM generated by gnutls_rsa_params_export_pkcs1 and
 gnutls_dh_params_import_pkcs3
References: <cone.1214173730.370910.24152.500@commodore.email-scan.com>
	<485EDF38.304@gnutls.org>
Message-ID: <cone.1214184488.704086.28826.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> Sam Varshavchik wrote:
>> The buffer size return value from gnutls_dh_params_import_pkcs3(), when
>> specifying GNUTLS_X509_FMT_PEM, seems to include a trailing \0 byte,
>> after "-----END DH PARAMETERS-----<NL>". On the other hand,
>> gnutls_rsa_params_export_pkcs1() with GNUTLS_X509_FMT_PEM sets the
>> returned buffer size to not include any trailing \0, after "-----END RSA
>> PRIVATE KEY-----<NL>".
>> 
>> That's the behavior I've observed with 2.0.4; and I haven't yet built
>> 2.4.0. If that's the case, I'm not really sure if it's a major issue,
>> but perhaps this should be noted in the man pages.
> 
> Hello,
>  This is a bug for sure, thank you for reporting it. Does the attached
> patch solve your issue?

Yes, with this patch gnutls_dh_params_import_pkcs3() no longer produces the 
trailing null byte.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20080622/5e312c6e/attachment.pgp>

From novel at FreeBSD.org  Mon Jun 23 17:54:18 2008
From: novel at FreeBSD.org (Roman Bogorodskiy)
Date: Mon, 23 Jun 2008 19:54:18 +0400
Subject: building gnutls 2.3.15 with opencdk installed
In-Reply-To: <20080619113846.GA1967@underworld.novel.ru>
References: <20080619050310.GA46818@underworld.novel.ru>
	<87iqw5n4wn.fsf@mocca.josefsson.org>
	<20080619113846.GA1967@underworld.novel.ru>
Message-ID: <20080623155418.GA38624@underworld.novel.ru>

  Roman Bogorodskiy wrote:

> I guess "-I/usr/local/include" appears here in place of $(LIBGCRYPT_CFLAGS). So the 
> problem probably could be fixed by changing -I flags order in
> AM_CPPFLAGS, i.e. placing opencdk stuff before $(LIBGCRYPT_CFLAGS). But
> I'm not sure, I cannot test it at this moment, will be able to check a
> bit later. 

It seems my guess was correct, after applying this patch:
http://people.freebsd.org/~novel/misc/gnutls-lib-Makefile.am.diff

it builds alright.

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

From simon at josefsson.org  Mon Jun 23 21:34:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Jun 2008 21:34:08 +0200
Subject: building gnutls 2.3.15 with opencdk installed
In-Reply-To: <20080623155418.GA38624@underworld.novel.ru> (Roman Bogorodskiy's
	message of "Mon, 23 Jun 2008 19:54:18 +0400")
References: <20080619050310.GA46818@underworld.novel.ru>
	<87iqw5n4wn.fsf@mocca.josefsson.org>
	<20080619113846.GA1967@underworld.novel.ru>
	<20080623155418.GA38624@underworld.novel.ru>
Message-ID: <87ve00ymhb.fsf@mocca.josefsson.org>

Roman Bogorodskiy <novel at FreeBSD.org> writes:

>   Roman Bogorodskiy wrote:
>
>> I guess "-I/usr/local/include" appears here in place of $(LIBGCRYPT_CFLAGS). So the 
>> problem probably could be fixed by changing -I flags order in
>> AM_CPPFLAGS, i.e. placing opencdk stuff before $(LIBGCRYPT_CFLAGS). But
>> I'm not sure, I cannot test it at this moment, will be able to check a
>> bit later. 
>
> It seems my guess was correct, after applying this patch:
> http://people.freebsd.org/~novel/misc/gnutls-lib-Makefile.am.diff
>
> it builds alright.

Makes sense, applied both to master and the gnutls_2_4_x branch.

/Simon




From gnutls-dev at mlists.thewrittenword.com  Wed Jun 25 01:59:51 2008
From: gnutls-dev at mlists.thewrittenword.com (Albert Chin)
Date: Tue, 24 Jun 2008 18:59:51 -0500
Subject: On dropping -D_REENTRANT -D_THREAD_SAFE
In-Reply-To: <87r6gtl4r6.fsf@mocca.josefsson.org>
References: <87wsqppm4v.fsf@mocca.josefsson.org>
	<200801061556.51625.nmav@gnutls.org>
	<87ejcv2g4e.fsf@mocca.josefsson.org>
	<87prwf0wjv.fsf@mocca.josefsson.org> <82tzlp7t2e.fsf@mid.bfk.de>
	<87r6gtl4r6.fsf@mocca.josefsson.org>
Message-ID: <20080624235951.GG24964@honinbu.il.thewrittenword.com>

On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
> Florian Weimer <fweimer at bfk.de> writes:
> 
> > * Simon Josefsson:
> >
> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> >> cfg/shared.c: In function `store_single_arg':
> >> cfg/shared.c:727: error: wrong type argument to unary plus
> >> cfg/shared.c:727: error: wrong type argument to unary minus
> >>
> >> The line reads:
> >>
> >> 			if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
> >
> > Looks like a GCC bug to me.  I can't reproduce this with:
> >
> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> 
> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
> suspect doesn't have enough administrative TLC to have properly
> installed tools.  So unless someone else reports the same issue, let's
> ignore it.

We see it with gcc-3.4.4 on Solaris 10/SPARC.

-- 
albert chin (china at thewrittenword.com)




From simon at josefsson.org  Wed Jun 25 12:44:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Jun 2008 12:44:31 +0200
Subject: HUGE_VAL on Solaris (was: Re: On dropping -D_REENTRANT
	-D_THREAD_SAFE)
References: <87wsqppm4v.fsf@mocca.josefsson.org>
	<200801061556.51625.nmav@gnutls.org>
	<87ejcv2g4e.fsf@mocca.josefsson.org>
	<87prwf0wjv.fsf@mocca.josefsson.org> <82tzlp7t2e.fsf@mid.bfk.de>
	<87r6gtl4r6.fsf@mocca.josefsson.org>
	<20080624235951.GG24964@honinbu.il.thewrittenword.com>
Message-ID: <87vdzxn69c.fsf@mocca.josefsson.org>

Albert Chin <gnutls-dev at mlists.thewrittenword.com> writes:

> On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
>> Florian Weimer <fweimer at bfk.de> writes:
>> 
>> > * Simon Josefsson:
>> >
>> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
>> >> cfg/shared.c: In function `store_single_arg':
>> >> cfg/shared.c:727: error: wrong type argument to unary plus
>> >> cfg/shared.c:727: error: wrong type argument to unary minus
>> >>
>> >> The line reads:
>> >>
>> >> 			if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
>> >
>> > Looks like a GCC bug to me.  I can't reproduce this with:
>> >
>> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
>> 
>> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
>> suspect doesn't have enough administrative TLC to have properly
>> installed tools.  So unless someone else reports the same issue, let's
>> ignore it.
>
> We see it with gcc-3.4.4 on Solaris 10/SPARC.

Indeed the problem seems real, however it seems to be a gcc bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933

A patch for gcc back-ported to 3.4.x is:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html

I can't test the patch, but it seems to address the problem.

Does any of the suggested work-arounds work for you?  I.e., add the
following before the line containing "cfg+.h" in src/cfg/shared.c:

#define HUGE_VAL (__builtin_huge_val())

This work-around appears to work on the solaris 5.10 I have access to.

I'm not sure if we can detect this brokenness in a clean way, but
patches are welcome.  Otherwise, perhaps this message can serve as
sufficient documentation to work around this gcc problem.

/Simon




From dkg-debian.org at fifthhorseman.net  Fri Jun 27 07:50:36 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Jun 2008 01:50:36 -0400
Subject: lib/opencdk/read-packet.c: read_s2k() implementation
Message-ID: <87skuzo28j.fsf@squeak.fifthhorseman.net>

Hey folks--

After wrapping my head around the relevant section of RFC 4880 and
bits of opencdk, i've fleshed out the previously unimplemented opencdk
internal function intended to interpret OpenPGP String-To-Key
transformations, read_s2k() in read-packet.c.

Attached, please find the patch for this function.  Inspection with a
debugger shows that the values being stored are congruent with what is
expected in other uses of the cdk_s2k_t construct.

After my first draft of this patch, i noticed that similar code
already existed in the read_symkey_enc() function (also in
lib/opencdk/read-packet.c).  So instead of publishing my first draft,
i've collapsed the code for these two so that there's a canonical
implementation of reading s2k values present in the opencdk codebase.
The attached patch reflects this approach.

This change should not affect the API or ABI at all, and it allows
GnuTLS to recognize encrypted secret keys (though it cannot yet use
them, afaict).

This patch was done against Andreas Metzler's 2.4.0-2 package of
gnutls that is currently in debian/unstable.

As always, feedback is welcome.

Regards,

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16_functional_read_s2k.diff
Type: text/x-diff
Size: 2126 bytes
Desc: enable read_s2k() in src/opencdk/read-packet.c
URL: </pipermail/attachments/20080627/1d8811f2/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080627/1d8811f2/attachment.pgp>

From n.mavrogiannopoulos at gmail.com  Fri Jun 27 12:21:12 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 27 Jun 2008 13:21:12 +0300
Subject: lib/opencdk/read-packet.c: read_s2k() implementation
In-Reply-To: <87skuzo28j.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
Message-ID: <c331d99a0806270321w32d3e34bq75e1dbac2f0c5e86@mail.gmail.com>

Hello Daniel,
 In a few days I'll merge with the new opencdk code in the development
branch (changes almost all code), thus I'd appreciate if you could
port your patch there.

regards,
Nikos

On Fri, Jun 27, 2008 at 8:50 AM, Daniel Kahn Gillmor
<dkg-debian.org at fifthhorseman.net> wrote:
> Hey folks--
>
> After wrapping my head around the relevant section of RFC 4880 and
> bits of opencdk, i've fleshed out the previously unimplemented opencdk
> internal function intended to interpret OpenPGP String-To-Key
> transformations, read_s2k() in read-packet.c.
>
> Attached, please find the patch for this function.  Inspection with a
> debugger shows that the values being stored are congruent with what is
> expected in other uses of the cdk_s2k_t construct.
>
> After my first draft of this patch, i noticed that similar code
> already existed in the read_symkey_enc() function (also in
> lib/opencdk/read-packet.c).  So instead of publishing my first draft,
> i've collapsed the code for these two so that there's a canonical
> implementation of reading s2k values present in the opencdk codebase.
> The attached patch reflects this approach.
>
> This change should not affect the API or ABI at all, and it allows
> GnuTLS to recognize encrypted secret keys (though it cannot yet use
> them, afaict).
>
> This patch was done against Andreas Metzler's 2.4.0-2 package of
> gnutls that is currently in debian/unstable.
>
> As always, feedback is welcome.
>
> Regards,
>
>        --dkg
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
>




From dkg-debian.org at fifthhorseman.net  Fri Jun 27 17:01:49 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 27 Jun 2008 11:01:49 -0400
Subject: lib/opencdk/read-packet.c: read_s2k() implementation
In-Reply-To: <c331d99a0806270321w32d3e34bq75e1dbac2f0c5e86@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Fri\,
	27 Jun 2008 13\:21\:12 +0300")
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
	<c331d99a0806270321w32d3e34bq75e1dbac2f0c5e86@mail.gmail.com>
Message-ID: <878wwqhqg2.fsf@squeak.fifthhorseman.net>

On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:

>  In a few days I'll merge with the new opencdk code in the
> development branch (changes almost all code), thus I'd appreciate if
> you could port your patch there.

It's not clear to me what branch you're specifically talking about.  I
see no branches named anything like "new opencdk" or "development" --
do you mean "gnutls_with_ext_mpi" ?

In my message on the "2.6.x goals" thread [0], i asked if me doing
work on these would be likely to collide with anyone else's work, and
got no response from you.  It would be useful for collaboration if we
can communicate with each other about this sort of thing.  Sorry for
the miscommunication from my end!

If the branch you're referring to *is* gnutls_with_ext_mpi, then it's
not clear to me how to port this properly.  CDK_PKT_SYMKEY_ENC is the
packet type whose parser contained the code i ended up moving into
read_s2k.  But CDK_PKT_SYMKEY_ENC appears to have been removed from
opencdk.h on the gnutls_with_ext_mpi branch, despite being clearly
defined in the standard [1].  Any reason this was removed?  It seems
like a useful packet type for OpenCDK to be able to handle.

I'm attaching an (untested) patch against the gnutls_with_ext_mpi
branch, which at least fleshes out the read_s2k function.

It's untested because when i still don't know how to build from the
git repo.  The developer's site says [2] "Build GnuTLS/libtasn1 by
running 'make' twice (once to run autoreconf and configure and another
time to build the code)", but when i try, even the first make fails:

[0 dkg at squeak git-gnutls]$ git status
# Not currently on any branch.
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   lib/opencdk/read-packet.c
#
no changes added to commit (use "git add" and/or "git commit -a")
[1 dkg at squeak git-gnutls]$ make
for f in po/*.po.in; do \
		cp $f `echo $f | sed 's/.in//'`; \
	done
mv build-aux/config.rpath build-aux/config.rpath-
test -f ./configure || autoreconf --install
mv build-aux/config.rpath- build-aux/config.rpath
./configure --enable-developer-mode --enable-gtk-doc
configure: error: cannot find install-sh or install.sh in build-aux "."/build-aux
make: *** [bootstrap] Error 1
[2 dkg at squeak git-gnutls]$ ls -l build-aux/
total 44
-rwxr-xr-x 1 dkg dkg 18343 2008-06-27 09:25 config.rpath
-rwxr-xr-x 1 dkg dkg 12050 2008-05-03 11:06 gendocs.sh
-rwxr-xr-x 1 dkg dkg  4735 2008-04-17 13:46 gnupload
-rw-r--r-- 1 dkg dkg  1292 2008-04-02 14:26 link-warning.h
[0 dkg at squeak git-gnutls]$ 

Any advice or pointers to better documentation would be welcome!

Regards,

    --dkg

[0] http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2908/focus=2909

  (the pipermail archives at http://lists.gnupg.org/pipermail/ are
  giving me a 403 forbidden error)

[1] http://tools.ietf.org/html/rfc4880#section-5.3

[2] http://trac.gnutls.org/cgi-bin/trac.cgi#SourceCode

-------------- next part --------------
A non-text attachment was scrubbed...
Name: functional_read_s2k-against-gnutls_with_ext_mpi.diff
Type: text/x-diff
Size: 1026 bytes
Desc: enable read_s2k() in src/opencdk/read-packet.c for gnutls_with_ext_mpi branch
URL: </pipermail/attachments/20080627/ccec94ad/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080627/ccec94ad/attachment.pgp>

From nmav at gnutls.org  Fri Jun 27 21:05:54 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 27 Jun 2008 22:05:54 +0300
Subject: lib/opencdk/read-packet.c: read_s2k() implementation
In-Reply-To: <878wwqhqg2.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<c331d99a0806270321w32d3e34bq75e1dbac2f0c5e86@mail.gmail.com>
	<878wwqhqg2.fsf@squeak.fifthhorseman.net>
Message-ID: <48653A12.1060709@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:
> 
>>  In a few days I'll merge with the new opencdk code in the
>> development branch (changes almost all code), thus I'd appreciate if
>> you could port your patch there.
> 
> It's not clear to me what branch you're specifically talking about.  I
> see no branches named anything like "new opencdk" or "development" --
> do you mean "gnutls_with_ext_mpi" ?

Yes this is the branch and sorry for any inconvenience this might have
caused to you. I'm working on this branch but due to my very limited
free time I couldn't safely merge with the rest of the code. I plan to
do it this weekend.

> In my message on the "2.6.x goals" thread [0], i asked if me doing
> work on these would be likely to collide with anyone else's work, and
> got no response from you. 

Probably I missed this email. Sorry again for any inconvenience.

> If the branch you're referring to *is* gnutls_with_ext_mpi, then it's
> not clear to me how to port this properly.  CDK_PKT_SYMKEY_ENC is the
> packet type whose parser contained the code i ended up moving into
> read_s2k.  But CDK_PKT_SYMKEY_ENC appears to have been removed from
> opencdk.h on the gnutls_with_ext_mpi branch, despite being clearly
> defined in the standard [1].  Any reason this was removed?  It seems
> like a useful packet type for OpenCDK to be able to handle.

Could be. I only kept the ones that are used for gnutls because I wanted
to avoid having the symmetric encryption. It seems we now with your
patch need it. Please feel free to reintroduce it.

> I'm attaching an (untested) patch against the gnutls_with_ext_mpi
> branch, which at least fleshes out the read_s2k function.

Does it work without any additions to this branch?

> Any advice or pointers to better documentation would be welcome!

I just run
autoreconf -fvi
./configure
and make

regards,
Nikos




From mrsam at courier-mta.com  Sat Jun 28 03:01:46 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Fri, 27 Jun 2008 21:01:46 -0400
Subject: Memory leak in _gnutls_mpi_dprint_lz (possibly _gnutls_mpi_dprint)
Message-ID: <cone.1214614906.362867.10352.500@commodore.email-scan.com>

I'm chasing a complaint from valgrind that I'm leaking memory.

Here's valgrind's complaint:

==26738== 257 bytes in 1 blocks are definitely lost in loss record 2 of 4
==26738==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==26738==    by 0x35068328F6: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
==26738==    by 0x350683E47C: _gnutls_dh_set_peer_public (gnutls_state.c:474)
==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx (auth_dh_common.c:297)
==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message (gnutls_kx.c:339)
==26738==    by 0x35068273DF: _gnutls_handshake_client (gnutls_handshake.c:2311)
==26738==    by 0x3506827F77: gnutls_handshake (gnutls_handshake.c:2193)


Here's what I've been able to figure out. I'm running gnutls 2.0.4, but I 
checked 2.4.0, and the affected bits have not changed, the following should 
still be applicable.

_gnutls_mpi_dprint_lz() allocates a buffer:

  if (bytes != 0)
    buf = gnutls_malloc (bytes);

. . . and puts it into its gnutls_datum_t parameter:

  if (!ret)
    {
      dest->data = buf;
      dest->size = bytes;
      return 0;
    }


If I set a breakpoint in _gnutls_dh_set_peer_public(), then I find that this 
breakpoint gets hit twice from gnutls_handshake():

#0  _gnutls_dh_set_peer_public (session=0x144fcc0, public=0x1431a70)
    at gnutls_state.c:474
#1  0x000000350684381a in _gnutls_proc_dh_common_server_kx (
    session=<value optimized out>, data=<value optimized out>, 
    _data_size=<value optimized out>, psk=<value optimized out>)
    at auth_dh_common.c:297
#2  0x000000350683bb50 in proc_dhe_server_kx (session=<value optimized out>, 
    data=<value optimized out>, _data_size=<value optimized out>)
    at auth_dhe.c:199
#3  0x000000350682af82 in _gnutls_recv_server_kx_message (
    session=<value optimized out>) at gnutls_kx.c:339
#4  0x00000035068273e0 in _gnutls_handshake_client (
    session=<value optimized out>) at gnutls_handshake.c:2311
#5  0x0000003506827f78 in gnutls_handshake (session=<value optimized out>)
    at gnutls_handshake.c:2193

Second breakpoint hit:

#0  _gnutls_dh_set_peer_public (session=0x144fcc0, public=0x1431a70)
    at gnutls_state.c:474
#1  0x0000003506843b8f in _gnutls_gen_dh_common_client_kx (
    session=<value optimized out>, data=<value optimized out>)
    at auth_dh_common.c:167
#2  0x000000350682aac1 in _gnutls_send_client_kx_message (
    session=<value optimized out>, again=<value optimized out>)
    at gnutls_kx.c:231
#3  0x000000350682736d in _gnutls_handshake_client (
    session=<value optimized out>) at gnutls_handshake.c:2352
#4  0x0000003506827f78 in gnutls_handshake (session=<value optimized out>)
    at gnutls_handshake.c:2193

Observe that _gnutls_dh_set_peer_public() invokes _gnutls_mpi_dprint_lz(), 
passing it the address of _gnutls_get_auth_info(session)->dh.public_key.

I hit the breakpoint the first time:

(gdb) p dh
$20 = (dh_info_st *) 0x8da8f8
(gdb) p $20->public_key
$21 = {data = 0x0, size = 0}

Empty unallocated buffer. Let me step into and out of the 
_gnutls_mpi_dprint_lz() function call:

(gdb) s
_gnutls_mpi_dprint_lz (dest=<value optimized out>, a=<value optimized out>)
    at gnutls_mpi.c:135
135	{
(gdb) finish
Run till exit from #0  _gnutls_mpi_dprint_lz (dest=<value optimized out>, 
    a=<value optimized out>) at gnutls_mpi.c:135
_gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:475
475	  if (ret < 0)
Value returned is $22 = 0
(gdb) p $20->public_key
$23 = {data = 0x8e2cd0 "", size = 257}

_gnutls_mpi_dprint_lz() does its thing, and returns, leaving the public_key 
datum allocated. Fine.

I'm going to let it run now, and let it hit the breakpoint the 2nd time:

(gdb) c
Continuing.

Breakpoint 3, _gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:474
474	  ret = _gnutls_mpi_dprint_lz (&dh?public_key, public);
(gdb) p dh
$24 = (dh_info_st *) 0x8da8f8
(gdb) p $24->public_key
$25 = {data = 0x8e2cd0 "", size = 257}

The buffer is still there, where it was before. Now you can see what's going 
to happen:

(gdb) s
_gnutls_mpi_dprint_lz (dest=<value optimized out>, a=<value optimized out>)
    at gnutls_mpi.c:135
135	{
(gdb) finish
Run till exit from #0  _gnutls_mpi_dprint_lz (dest=<value optimized out>, 
    a=<value optimized out>) at gnutls_mpi.c:135
_gnutls_dh_set_peer_public (session=0x8d9bd0, public=0x8ad2b0)
    at gnutls_state.c:475
475	  if (ret < 0)
Value returned is $26 = 0
(gdb) p $24->public_key
$27 = {data = 0x8e7460 "", size = 257}

_gnutls_mpi_dprint_lz() did not check that its datum parameter was already 
initialized with a memory chunk, and allocated another memory block, 
overwriting the pointer, and leaking that memory block.

I cannot say what's the correct fix: have _gnutls_mpi_dprint_lz() clean up 
its gnutls_datum_t parameter, if it already points to some other memory 
chunk, or have _gnutls_dh_set_peer_public() check if dh->public_key is 
already initialized, and avoid calling _gnutls_mpi_dprint_lz() if so.

I also see the same logic in _gnutls_mpi_dprint() as well, there's a good 
possibility that there are execution paths that might trigger a leak there 
as well.





From gnutls-devel at mlists.thewrittenword.com  Wed Jun 25 22:40:31 2008
From: gnutls-devel at mlists.thewrittenword.com (Albert Chin)
Date: Wed, 25 Jun 2008 15:40:31 -0500
Subject: HUGE_VAL on Solaris (was: Re: On dropping -D_REENTRANT
	-D_THREAD_SAFE)
In-Reply-To: <87vdzxn69c.fsf@mocca.josefsson.org>
References: <87wsqppm4v.fsf@mocca.josefsson.org>
	<200801061556.51625.nmav@gnutls.org>
	<87ejcv2g4e.fsf@mocca.josefsson.org>
	<87prwf0wjv.fsf@mocca.josefsson.org> <82tzlp7t2e.fsf@mid.bfk.de>
	<87r6gtl4r6.fsf@mocca.josefsson.org>
	<20080624235951.GG24964@honinbu.il.thewrittenword.com>
	<87vdzxn69c.fsf@mocca.josefsson.org>
Message-ID: <20080625204031.GK26357@honinbu.il.thewrittenword.com>

On Wed, Jun 25, 2008 at 12:44:31PM +0200, Simon Josefsson wrote:
> Albert Chin <gnutls-dev at mlists.thewrittenword.com> writes:
> 
> > On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
> >> Florian Weimer <fweimer at bfk.de> writes:
> >> 
> >> > * Simon Josefsson:
> >> >
> >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> >> >> cfg/shared.c: In function `store_single_arg':
> >> >> cfg/shared.c:727: error: wrong type argument to unary plus
> >> >> cfg/shared.c:727: error: wrong type argument to unary minus
> >> >>
> >> >> The line reads:
> >> >>
> >> >> 			if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
> >> >
> >> > Looks like a GCC bug to me.  I can't reproduce this with:
> >> >
> >> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> >> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> >> 
> >> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
> >> suspect doesn't have enough administrative TLC to have properly
> >> installed tools.  So unless someone else reports the same issue, let's
> >> ignore it.
> >
> > We see it with gcc-3.4.4 on Solaris 10/SPARC.
> 
> Indeed the problem seems real, however it seems to be a gcc bug:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
> 
> A patch for gcc back-ported to 3.4.x is:
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html
> 
> I can't test the patch, but it seems to address the problem.

We have the patch.

> Does any of the suggested work-arounds work for you?  I.e., add the
> following before the line containing "cfg+.h" in src/cfg/shared.c:
> 
> #define HUGE_VAL (__builtin_huge_val())
> 
> This work-around appears to work on the solaris 5.10 I have access to.
> 
> I'm not sure if we can detect this brokenness in a clean way, but
> patches are welcome.  Otherwise, perhaps this message can serve as
> sufficient documentation to work around this gcc problem.

It's only a problem with --std=gnu99. We just build without that
(ac_cv_prog_cc_c99=no) and things are ok.

-- 
albert chin (china at thewrittenword.com)




From nmav at gnutls.org  Sat Jun 28 11:06:34 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 28 Jun 2008 12:06:34 +0300
Subject: lib/opencdk/read-packet.c: read_s2k() implementation
In-Reply-To: <878wwqhqg2.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<c331d99a0806270321w32d3e34bq75e1dbac2f0c5e86@mail.gmail.com>
	<878wwqhqg2.fsf@squeak.fifthhorseman.net>
Message-ID: <4865FF1A.4060301@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:
> 
> It's not clear to me what branch you're specifically talking about.  I
> see no branches named anything like "new opencdk" or "development" --
> do you mean "gnutls_with_ext_mpi" ?

The gnutls_with_ext_mpi branch has now been merged into master.

regards,
Nikos





From nmav at gnutls.org  Sun Jun 29 11:08:14 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 29 Jun 2008 12:08:14 +0300
Subject: Memory leak in _gnutls_mpi_dprint_lz (possibly
	_gnutls_mpi_dprint)
In-Reply-To: <cone.1214614906.362867.10352.500@commodore.email-scan.com>
References: <cone.1214614906.362867.10352.500@commodore.email-scan.com>
Message-ID: <486750FE.2090002@gnutls.org>

Sam Varshavchik wrote:

> I'm chasing a complaint from valgrind that I'm leaking memory.
> Here's valgrind's complaint:
> 
> ==26738== 257 bytes in 1 blocks are definitely lost in loss record 2 of 4
> ==26738==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
> ==26738==    by 0x35068328F6: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
> ==26738==    by 0x350683E47C: _gnutls_dh_set_peer_public
> (gnutls_state.c:474)
> ==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx
> (auth_dh_common.c:297)
> ==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
> ==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message
> (gnutls_kx.c:339)
> ==26738==    by 0x35068273DF: _gnutls_handshake_client
> (gnutls_handshake.c:2311)
> ==26738==    by 0x3506827F77: gnutls_handshake (gnutls_handshake.c:2193)
> 
> 
> Here's what I've been able to figure out. I'm running gnutls 2.0.4, but
> I checked 2.4.0, and the affected bits have not changed, the following
> should still be applicable.

Hello Sam and thank you for there report. However is this issue present
in 2.4.x or 2.2.x? I've seen that there _gnutls_dh_set_peer_public() is
only called by:
_gnutls_proc_dh_common_client_kx (server side only)
_gnutls_proc_dh_common_server_kx (client side only)

Thus this leak could not have occurred.

> Second breakpoint hit:
> 
> #0  _gnutls_dh_set_peer_public (session=0x144fcc0, public=0x1431a70)
>    at gnutls_state.c:474
> #1  0x0000003506843b8f in _gnutls_gen_dh_common_client_kx (
>    session=<value optimized out>, data=<value optimized out>)
>    at auth_dh_common.c:167

This is no longer an issue in 2.2.x or 2.4.x thus I'd suggest you
upgrade. If you cannot a tiny patch is attached.

regards,
Nikos


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20080629/c67aee61/attachment.txt>

From mrsam at courier-mta.com  Sun Jun 29 15:17:24 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 29 Jun 2008 09:17:24 -0400
Subject: Memory leak in _gnutls_mpi_dprint_lz (possibly
 _gnutls_mpi_dprint)
References: <cone.1214614906.362867.10352.500@commodore.email-scan.com>
	<486750FE.2090002@gnutls.org>
Message-ID: <cone.1214745444.68316.13036.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> Sam Varshavchik wrote:
> 
>> I'm chasing a complaint from valgrind that I'm leaking memory.
>> Here's valgrind's complaint:
>> 
>> ==26738== 257 bytes in 1 blocks are definitely lost in loss record 2 of 4
>> ==26738==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
>> ==26738==    by 0x35068328F6: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
>> ==26738==    by 0x350683E47C: _gnutls_dh_set_peer_public
>> (gnutls_state.c:474)
>> ==26738==    by 0x3506843819: _gnutls_proc_dh_common_server_kx
>> (auth_dh_common.c:297)
>> ==26738==    by 0x350683BB4F: proc_dhe_server_kx (auth_dhe.c:199)
>> ==26738==    by 0x350682AF81: _gnutls_recv_server_kx_message
>> (gnutls_kx.c:339)
>> ==26738==    by 0x35068273DF: _gnutls_handshake_client
>> (gnutls_handshake.c:2311)
>> ==26738==    by 0x3506827F77: gnutls_handshake (gnutls_handshake.c:2193)
>> 
>> 
>> Here's what I've been able to figure out. I'm running gnutls 2.0.4, but
>> I checked 2.4.0, and the affected bits have not changed, the following
>> should still be applicable.
> 
> Hello Sam and thank you for there report. However is this issue present
> in 2.4.x or 2.2.x? I've seen that there _gnutls_dh_set_peer_public() is
> only called by:
> _gnutls_proc_dh_common_client_kx (server side only)
> _gnutls_proc_dh_common_server_kx (client side only)
> 
> Thus this leak could not have occurred.

Thanks for looking into this. I see what you mean. Initially I did also look 
at 2.4.0, but I only looked at _gnutls_dh_set_peer_public() and 
_gnutls_mpi_dprint_lz()  and didn't see much changes; but I haven't checked 
the execution paths in 2.4.0 that reach this function. After compiling 
against 2.4.0, valgrind no longer shows this leak.

But given that there still does not seem to be an explicit check in 
_gnutls_mpi_dprint_lz() for a previously-allocated buffer, I'm now wondering 
what happens if a rehandshake occurs in a middle of a session. I'll try to 
write some code to test this, against 2.4.0, and see what happens.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20080629/5c518d94/attachment.pgp>

From nmav at gnutls.org  Sun Jun 29 21:21:11 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 29 Jun 2008 22:21:11 +0300
Subject: Memory leak in _gnutls_mpi_dprint_lz (possibly
	_gnutls_mpi_dprint)
In-Reply-To: <cone.1214745444.68316.13036.500@commodore.email-scan.com>
References: <cone.1214614906.362867.10352.500@commodore.email-scan.com>
	<486750FE.2090002@gnutls.org>
	<cone.1214745444.68316.13036.500@commodore.email-scan.com>
Message-ID: <4867E0A7.40305@gnutls.org>

Sam Varshavchik wrote:

> But given that there still does not seem to be an explicit check in
> _gnutls_mpi_dprint_lz() for a previously-allocated buffer, I'm now
> wondering what happens if a rehandshake occurs in a middle of a session.
> I'll try to write some code to test this, against 2.4.0, and see what
> happens.

You're right, there might be an issue there. I've added some check to
protect against this case.

regards,
Nikos






From mkoenig at suse.de  Mon Jun 30 10:21:43 2008
From: mkoenig at suse.de (Matthias Koenig)
Date: Mon, 30 Jun 2008 10:21:43 +0200
Subject: [PATCH] srptool, fix problem where passwords never match
Message-ID: <n7xmyl3l4dk.fsf@sor.suse.de>

Hi,

this fixes a problem in srptool, where the passwords never match
(--verify check) on some architectures (I think I have observed
this only on i386). It is for 1.6.1, but still applies to 2.4.0.

Matthias

Index: gnutls-1.6.1/src/crypt.c
===================================================================
--- gnutls-1.6.1.orig/src/crypt.c
+++ gnutls-1.6.1/src/crypt.c
@@ -220,6 +220,7 @@ _verify_passwd_int (const char *username
 
   /* encode the verifier into _salt */
   salt_size = sizeof (_salt);
+  memset(_salt, '\0', salt_size);
   if (gnutls_srp_base64_encode (&new_verifier, _salt, &salt_size) < 0)
     {
       fprintf (stderr, "Encoding error\n");




From simon at josefsson.org  Mon Jun 30 11:18:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 30 Jun 2008 11:18:46 +0200
Subject: HUGE_VAL on Solaris
In-Reply-To: <20080625204031.GK26357@honinbu.il.thewrittenword.com> (Albert
	Chin's message of "Wed, 25 Jun 2008 15:40:31 -0500")
References: <87wsqppm4v.fsf@mocca.josefsson.org>
	<200801061556.51625.nmav@gnutls.org>
	<87ejcv2g4e.fsf@mocca.josefsson.org>
	<87prwf0wjv.fsf@mocca.josefsson.org> <82tzlp7t2e.fsf@mid.bfk.de>
	<87r6gtl4r6.fsf@mocca.josefsson.org>
	<20080624235951.GG24964@honinbu.il.thewrittenword.com>
	<87vdzxn69c.fsf@mocca.josefsson.org>
	<20080625204031.GK26357@honinbu.il.thewrittenword.com>
Message-ID: <878wwn7021.fsf@mocca.josefsson.org>

Albert Chin <gnutls-devel at mlists.thewrittenword.com> writes:

>> Does any of the suggested work-arounds work for you?  I.e., add the
>> following before the line containing "cfg+.h" in src/cfg/shared.c:
>> 
>> #define HUGE_VAL (__builtin_huge_val())
>> 
>> This work-around appears to work on the solaris 5.10 I have access to.
>> 
>> I'm not sure if we can detect this brokenness in a clean way, but
>> patches are welcome.  Otherwise, perhaps this message can serve as
>> sufficient documentation to work around this gcc problem.
>
> It's only a problem with --std=gnu99. We just build without that
> (ac_cv_prog_cc_c99=no) and things are ok.

Ok, great, so there are two workarounds for the compiler problem in case
someone else runs into this as well.

/Simon




From nmav at gnutls.org  Mon Jun 30 19:42:29 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 30 Jun 2008 20:42:29 +0300
Subject: [PATCH] srptool, fix problem where passwords never match
In-Reply-To: <n7xmyl3l4dk.fsf@sor.suse.de>
References: <n7xmyl3l4dk.fsf@sor.suse.de>
Message-ID: <48691B05.5020804@gnutls.org>

Matthias Koenig wrote:
> Hi,
> 
> this fixes a problem in srptool, where the passwords never match
> (--verify check) on some architectures (I think I have observed
> this only on i386). It is for 1.6.1, but still applies to 2.4.0.

Applied. Thank you.

regards,
Nikos




From simon at josefsson.org  Mon Jun 30 23:36:52 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 30 Jun 2008 23:36:52 +0200
Subject: GnuTLS 2.4.1
Message-ID: <87skuuiozv.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.4.1.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains TLS/IA support, LZO compression -- and the
OpenSSL compatibility library self tests and command line tools are
distributed under the GNU General Public License version 3.0 (or later).
The manual is distributed under the GNU Free Documentation License
version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/

What's New
==========

Changes compared to the last stable release version 2.4.1:

** libgnutls: Fix local crash in gnutls_handshake.  [GNUTLS-SA-2008-2]
If the gnutls_handshake function is called for a normal session, which
can happen for re-handshakes, the library would crash because it tried
to hash some data using a libgcrypt handle that had been deallocated.
Report and tiny patch from Tomas Mraz <tmraz at redhat.com>.  Any updates
with more details about this vulnerability will be added to
<http://www.gnu.org/software/gnutls/security.html>

** libgnutls: Fix memory leaks when doing a re-handshake.
Reported by Sam Varshavchik <mrsam at courier-mta.com> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2928>.

** Fix compiler warnings.
Reported by Massimo Gaspari <massimo.gaspari at alice.it> in
<http://thread.gmane.org/gmane.network.gnutls.general/1281>.

** Fix ordering of -I's to avoid opencdk.h conflict with system headers.
Reported by Roman Bogorodskiy <novel at FreeBSD.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2930>.

** srptool: Fix a problem where --verify check does not succeed.
Report and tiny patch by Matthias Koenig <mkoenig at suse.de> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2944>.

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.1.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.4.1.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.1.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.4.1.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.4.1.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

7a439542e6344d5ccf11a29431a0600e7fe1c735  gnutls-2.4.1.tar.bz2

b38deef0f27412212b02c871e584d3ae9958c8d445de21c5496f2c49  gnutls-2.4.1.tar.bz2

Documentation
=============

The manual is available online at:

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

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:
<http://lists.gnupg.org/mailman/listinfo/gnutls-dev>.

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.4.1.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.4.1.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.4.1.exe.sig

The checksum values for SHA-1 and SHA-224 are:

a629764717b16f545e0a91f116215df36c5219fe  gnutls-2.4.1.exe

0d3cdd14f01d58644045d440ef95fc78ab55de03e605999621b601d7  gnutls-2.4.1.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.4.1-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

92a1efe32fe3e3e14807a4b4543e5902ef56389c  mingw32-gnutls_2.4.1-1_all.deb

a0776c2f5cc3e06d79fc1df3bc58cbf59e2b5ed920c72a6ac53e9139  mingw32-gnutls_2.4.1-1_all.deb

Internationalization
====================

GnuTLS messages have been translated into Dutch, German, Malay, Polish,
Swedish, and Vietnamese.  We welcome the addition of more translations.

Support
=======

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.

The GnuTLS service directory is available at:

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

Happy Hacking,
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/20080630/4709736e/attachment.pgp>

From simon at josefsson.org  Mon Jun 30 23:42:18 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 30 Jun 2008 23:42:18 +0200
Subject: Details on the gnutls_handshake local crash problem
	[GNUTLS-SA-2008-2]
Message-ID: <87myl2ioqt.fsf@mocca.josefsson.org>

Below is my analysis of the problem.  The patch is short:

>From 0fee3917077e191dea3c9787c95c072979532086 Mon Sep 17 00:00:00 2001
From: Simon Josefsson <simon at josefsson.org>
Date: Mon, 30 Jun 2008 22:44:47 +0200
Subject: [PATCH] (_gnutls_handshake_hash_buffers_clear): Make sure deinitialized MAC hashes are initialized.
 Report and tiny patch from Tomas Mraz <tmraz at redhat.com>.

---
 lib/gnutls_handshake.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c
index d798180..0192c9f 100644
--- a/lib/gnutls_handshake.c
+++ b/lib/gnutls_handshake.c
@@ -69,11 +69,12 @@ int _gnutls_server_select_comp_method (gnutls_session_t session,
 
 /* Clears the handshake hash buffers and handles.
  */
-inline static void
+static void
 _gnutls_handshake_hash_buffers_clear (gnutls_session_t session)
 {
   _gnutls_hash_deinit (&session->internals.handshake_mac_handle_md5, NULL);
   _gnutls_hash_deinit (&session->internals.handshake_mac_handle_sha, NULL);
+  session->internals.handshake_mac_handle_init = 0;
   _gnutls_handshake_buffer_clear (session);
 }
 
-- 
1.5.6

/Simon

I have received a report against gnutls v2.4.0 which triggers a local
segmentation fault when any application calls gnutls_handshake() for an
already valid session.  This is valid but not common usage.

Btw, earlier stable releases before v2.4.0 are not affected.  The
problem was introduced in v2.3.5 in the first @@-section of:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=3aea821a6ce36bd14f2a3a41598db698d031fadc#patch5

How to reproduce:

1. download ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.0.tar.bz2
   you'll need libgpg-error/libgcrypt installed if you do not
   have it already
2. build it: ./configure && make
3. download
   'http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob_plain;f=tests/mini.c;h=HEAD;hb=HEAD'
   into tests/mini.c,
   the latest code triggers the behaviour.
4. run cd tests; make mini;./mini

Detailed analysis:

The code ends up invoking gcry_md_write() on a handle that points to a
free()'d structure.  Since the pointer has been free()'d, the pointer
could point to anything at the time when the code is invoked.  An
attacker can't control where the pointer points to, but an attacker
could have sent data into a buffer that is in the victims memory.  If
the pointer happens to point to the data buffer sent by the attacker,
the attacker may be able to control execution.

Libgcrypt's code is:

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/cipher/md.c?root=Libgcrypt&view=auto

static void
md_write (gcry_md_hd_t a, const void *inbuf, size_t inlen)
{
  GcryDigestEntry *r;
  
  if (a->ctx->debug)
    {
      if (a->bufpos && fwrite (a->buf, a->bufpos, 1, a->ctx->debug) != 1)
	BUG();
      if (inlen && fwrite (inbuf, inlen, 1, a->ctx->debug) != 1)
	BUG();
    }

  for (r = a->ctx->list; r; r = r->next)
    {
      if (a->bufpos)
	(*r->digest->write) (&r->context.c, a->buf, a->bufpos);
      (*r->digest->write) (&r->context.c, inbuf, inlen);
    }
  a->bufpos = 0;
}

For me, the crash happens because a->ctx is still valid but
a->ctx->debug is garbage, so it crashes in the fwrite, writing to a bad
file descriptor.

Given that the code de-reference a->ctx->list or a->buf early, which is
typically garbage, normally the code will crash before using any of the
inbuf/inlen data.

The inbuf/inlen data is normally not under attacker control, it is
generated by the local implementation to be a TLS handshake packet.
However, some elements of the TLS handshake packets may have been
influenced by the other side during the first handshake, so the
conservative approach would be to treat it as tainted.

To turn this into an exploit, I believe the attacker needs to cause some
specific data to be located where the free()'d pointer 'a' points.  To
do this reliable, you need to predict where the 'a' pointer will point
to and to put some custom data at that memory address.  Once that is
done, you could make the first fwrite() in the function above write some
data to an already open file descriptor.  Of course, the attacker needs
to know the address of the file descriptor, and make that address be
part of the data sent to to the victim.

However, causing custom data to be placed at the point where an earlier
free()'d pointer points to appears difficult to do on normal platforms
where you typically don't know the heap memory addresses.