From ametzler at downhill.at.eu.org  Thu Nov  1 10:34:56 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 1 Nov 2007 10:34:56 +0100
Subject: [gnutls-dev] Where to get OpenCDK 0.6.5
In-Reply-To: <20071028095730.GC4852@downhill.g.la>
References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net>
	<87640sqn5x.fsf@mocca.josefsson.org>
	<20071028080919.GA4852@downhill.g.la>
	<87y7dnmvvs.fsf@mocca.josefsson.org>
	<20071028095730.GC4852@downhill.g.la>
Message-ID: <20071101093456.GA4722@downhill.g.la>

On 2007-10-28 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> On 2007-10-28 Simon Josefsson <simon at josefsson.org> wrote:
> > Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
> > > According to libtool's manual this means that 2.0.1 supports
> > > interfaces 13, 14, 15, ..., 21 and that 2.1.5 only supports interface
> > > 14. This does not reflect the actual interface. However AFAICT it is
> > > going to work perfectly on Linux, since libtool cannot express this
> > > correctly just in a soname.
> [...]
> > Is there _any_ system on which libtool can express that semantic?

> That is the 100$ question. ;-)

> > I also think there is something broken in how this mapping works.

> Perhaps we wil get an answer from libtool upstream,
> <http://news.gmane.org/find-root.php?message_id=%3ch5udv4%2d3d9.ln1%40argenau.downhill.at.eu.org%3e>

Ralf Wildenhues has answered:
| * Andreas Metzler wrote on Sun, Oct 28, 2007 at 09:34:25AM CET:
| > 
| > [...] However, the way libtool
| > tries to represent this information in sonames (on Linux) is rather
| > strange, it goes straight from libgnutls.so.13 to libgnutls.so.23. Is
| > this huge jump just bug or is there a reason for it?
| 
| The reason for it is simplicity in the version number calculation.
| There is no requirement for version numbers to be consecutive except
| for "consecutive looks nicer" and the finite number space.  I assume
| its pressure to be far lower than the incompatible change a different
| version number calculation would make.
| 
| The way libtool computes them, it even causes different major version
| numbers on different systems, so the above jump is even specific to the
| linux version_type and not all types.

and in a later mail:
| Date: 2007-10-28 12:37:29 GMT (3 days, 20 hours and 49 minutes ago)
| 
| * Andreas Metzler wrote on Sun, Oct 28, 2007 at 01:28:54PM CET:
| > 
| > Are there libtool-supported archs whose versioning will break if we do
| > this
| > num   c       r       a
| > 2.1.1 22      1       9
| > 2.1.2 14      0       0
| > 
| > instead of
| > num   c       r       a
| > 2.1.1 22      1       9
| > 2.1.2 23      0       0
| > 
| > (I know it would work on linux, resulting in libgnutls.so.14.)
| 
| I think on FreeBSD it will cause a backward jump from libgnutls.so.22 to
| libgnutls.so.14.

> > Anyway, it seems we really should use c=25 then, to avoid any
> > possibility of problems on some systems?  We can make the change in
> > 2.1.5.

Looks like this is the way to go.

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



From simon at josefsson.org  Thu Nov  1 11:16:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 01 Nov 2007 11:16:39 +0100
Subject: [gnutls-dev] Where to get OpenCDK 0.6.5
In-Reply-To: <20071101093456.GA4722@downhill.g.la> (Andreas Metzler's message
	of "Thu, 1 Nov 2007 10:34:56 +0100")
References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net>
	<87640sqn5x.fsf@mocca.josefsson.org>
	<20071028080919.GA4852@downhill.g.la>
	<87y7dnmvvs.fsf@mocca.josefsson.org>
	<20071028095730.GC4852@downhill.g.la>
	<20071101093456.GA4722@downhill.g.la>
Message-ID: <873avquv7c.fsf@mocca.josefsson.org>

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

>> > Anyway, it seems we really should use c=25 then, to avoid any
>> > possibility of problems on some systems?  We can make the change in
>> > 2.1.5.
>
> Looks like this is the way to go.

Thanks for asking about this, I changed it to c=25 now.

/Simon



From simon at josefsson.org  Sat Nov  3 10:11:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 03 Nov 2007 10:11:33 +0100
Subject: [gnutls-dev] GnuTLS 2.1.5
Message-ID: <873avn7kxm.fsf@mocca.josefsson.org>

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

News in this release:

* Version 2.1.5 (released 2007-11-01)

** Fix PKCS#3 parameter export problem.

** Improve certtool queries, they now print the default value.

** Fix ABI version.

** Update gnulib files.

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

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

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

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.5.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.1.5.tar.bz2

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

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

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

From simon at josefsson.org  Mon Nov  5 10:03:40 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 Nov 2007 10:03:40 +0100
Subject: [gnutls-dev] GnuTLS 2.1.5
In-Reply-To: <873avn7kxm.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Sat, 03 Nov 2007 10:11:33 +0100")
References: <873avn7kxm.fsf@mocca.josefsson.org>
Message-ID: <87640hkqs3.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> The goals for the 2.1.x branch are tracked at:
>
> http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.2

I've set the release date for the GnuTLS 2.2 release for December 1th.
It may be a bit aggressive, but I hope we'll make it.  We want to get
this branch stable ASAP because it fixes several protocol bugs related
to OpenPGP and SRP.  Testing by packagers will be very welcome
feedback..

/Simon



From nmav at gnutls.org  Mon Nov  5 20:11:36 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 5 Nov 2007 21:11:36 +0200
Subject: [gnutls-dev] [Help-gnutls] RFC 5081 on Using OpenPGP Keys for
	Transport Layer Security (TLS) Authentication
In-Reply-To: <20071105110004.GA11165@nic.fr>
References: <20071105110004.GA11165@nic.fr>
Message-ID: <200711052111.36961.nmav@gnutls.org>

On Monday 05 November 2007, Stephane Bortzmeyer wrote:

> Congratulations to the author, TLS with PGP is now a RFC document.
> As far as I know, only GnuTLS implements this RFC?

I'm also not aware of other implementations. We plan to have a fully-working 
and supported implementation for the gnutls 2.2 release[0]. If there are 
people interested in implementing this technology, I'd suggest to use 
gnutls-2.1.5 and later versions. There are cleanups and updates to conform to 
the latest document.


regards,
Nikos


[0]. The code is already there but more testing is required.



From mkoenig at suse.de  Tue Nov  6 14:37:48 2007
From: mkoenig at suse.de (Matthias Koenig)
Date: Tue, 06 Nov 2007 14:37:48 +0100
Subject: [gnutls-dev] license link on gnutls webpage
Message-ID: <n7xbqa7pk9f.fsf@sor.suse.de>

Hi,

while GnuTLS is currently licensed under LGPLv2.1 or later
the license link on http://www.gnu.org/software/gnutls/ in the 
Overview section is a direkt link to the LGPLv3:
http://www.gnu.org/licenses/lgpl.html

This might confuse people.

Matthias



From simon at josefsson.org  Thu Nov  8 10:19:14 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 08 Nov 2007 10:19:14 +0100
Subject: [gnutls-dev] license link on gnutls webpage
In-Reply-To: <n7xbqa7pk9f.fsf@sor.suse.de> (Matthias Koenig's message of "Tue, 
	06 Nov 2007 14:37:48 +0100")
References: <n7xbqa7pk9f.fsf@sor.suse.de>
Message-ID: <87mytprt65.fsf@mocca.josefsson.org>

Matthias Koenig <mkoenig at suse.de> writes:

> Hi,
>
> while GnuTLS is currently licensed under LGPLv2.1 or later
> the license link on http://www.gnu.org/software/gnutls/ in the 
> Overview section is a direkt link to the LGPLv3:
> http://www.gnu.org/licenses/lgpl.html
>
> This might confuse people.

Hi!  Thanks for noticing this.  I have changed the link to the old
LGPLv2.1 page at gnu.org, and also mentioned 'version 2.1'.

/Simon



From nmav at gnutls.org  Sat Nov 10 15:54:44 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 10 Nov 2007 16:54:44 +0200
Subject: [gnutls-dev] mod_gnutls for apache
Message-ID: <200711101654.45014.nmav@gnutls.org>

Hello,
 I've modified the mod_gnutls apache module found in
http://www.outoforder.cc/projects/apache/mod_gnutls/, to add support 
for client certificate verification, SRP and more configurable options. The 
modified code is available for testing at 
http://members.hellug.gr/nmav/misc/apache/ .

There no formal instructions on how to set it up although the README file and
the instructions at 
http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
still apply.

This version works with gnutls-2.1.5 or later.

Testing is welcome as well as bug reports (to me).


regards,
Nikos



From martine at danga.com  Sun Nov 11 01:45:58 2007
From: martine at danga.com (Evan Martin)
Date: Sat, 10 Nov 2007 16:45:58 -0800
Subject: [gnutls-dev] [PATCH] fix english in a message
Message-ID: <1194741958-12912-1-git-send-email-martine@danga.com>

Languages differ as to whether negative sentences use negative quantifiers,
but in English they don't.  For that reason this message was a bit confusing.
---
 src/tls_test.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/tls_test.c b/src/tls_test.c
index 2134474..d34eec4 100644
--- a/src/tls_test.c
+++ b/src/tls_test.c
@@ -245,7 +245,7 @@ main (int argc, char **argv)
       if (i > 3 && tls1_1_ok == 0 && tls1_ok == 0 && ssl3_ok == 0)
 	{
 	  fprintf (stderr,
-		   "\nServer does not support none of SSL 3.0, TLS 1.0 and TLS 1.1\n");
+		   "\nServer does not support any of SSL 3.0, TLS 1.0 and TLS 1.1\n");
 	  break;
 	}
 
-- 
1.5.3.GIT




From martine at danga.com  Sun Nov 11 01:36:30 2007
From: martine at danga.com (Evan Martin)
Date: Sat, 10 Nov 2007 16:36:30 -0800
Subject: [gnutls-dev] [PATCH] fix doc referencing a non-public function
Message-ID: <1194741390-12752-1-git-send-email-martine@danga.com>

gnutls_x509_verify_certificate(), though mentioned in the docs, is not a
public function.  (Perhaps the API has changed?)  However,
gnutls_x509_crt_list_verify() is nearly identical to the internal function, so
let's change the docs to refer to that.
---
 lib/gnutls_cert.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
index 6e81372..378b08e 100644
--- a/lib/gnutls_cert.c
+++ b/lib/gnutls_cert.c
@@ -522,7 +522,7 @@ _gnutls_openpgp_crt_verify_peers (gnutls_session_t session,
   *
   * Returns a negative error code on error and zero on success.
   *
-  * This is the same as gnutls_x509_verify_certificate() and uses the
+  * This is the same as gnutls_x509_crt_list_verify() and uses the
   * loaded CAs in the credentials as trusted CAs.
   *
   * Note that some commonly used X.509 Certificate Authorities are
@@ -571,7 +571,7 @@ gnutls_certificate_verify_peers2 (gnutls_session_t session,
   * gnutls_certificate_status_t enumerated elements bitwise or'd, or a
   * negative value on error.
   *
-  * This is the same as gnutls_x509_verify_certificate().
+  * This is the same as gnutls_x509_crt_list_verify().
   *
   * Deprecated: Use gnutls_certificate_verify_peers2() instead.
   *
-- 
1.5.3.GIT




From martine at danga.com  Sun Nov 11 03:19:25 2007
From: martine at danga.com (Evan Martin)
Date: Sat, 10 Nov 2007 18:19:25 -0800
Subject: [gnutls-dev] gnutls_certificate_send_x509_rdn_sequence not exposed
In-Reply-To: <3a6f89fc0711101818v6bc70564xc1e8b173895285d@mail.gmail.com>
References: <3a6f89fc0711101627y58a351acx1e2573e1689ddffd@mail.gmail.com>
	<3a6f89fc0711101818v6bc70564xc1e8b173895285d@mail.gmail.com>
Message-ID: <3a6f89fc0711101819w16c52cebq9a97e84475e77797@mail.gmail.com>

The documentation refers to a function called
gnutls_certificate_send_x509_rdn_sequence(), but it's not public in
any header.
Is this intentional or an oversight?



From martine at danga.com  Sun Nov 11 03:19:58 2007
From: martine at danga.com (Evan Martin)
Date: Sat, 10 Nov 2007 18:19:58 -0800
Subject: [gnutls-dev] [PATCH] fix doc string to match parameter order and
	add a const
In-Reply-To: <1194741064-12653-1-git-send-email-martine@danga.com>
References: <1194741064-12653-1-git-send-email-martine@danga.com>
Message-ID: <3a6f89fc0711101819m247a6a81u45825116d2b18ad7@mail.gmail.com>

gnutls_certificate_client_set_retrieve_function: the callback prototype
listed was missing a "const".  Changed the document's parameter order to
match the prototype parameter order.
---
 lib/gnutls_cert.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
index 3eb7c2b..6e81372 100644
--- a/lib/gnutls_cert.c
+++ b/lib/gnutls_cert.c
@@ -314,19 +314,19 @@ gnutls_certificate_server_set_request
(gnutls_session_t session,
   * to be used in the handshake.
   * The callback's function prototype is:
   * int (*callback)(gnutls_session_t, const gnutls_datum_t*
req_ca_dn, int nreqs,
-  * gnutls_pk_algorithm_t* pk_algos, int pk_algos_length, gnutls_retr_st* st);
+  * const gnutls_pk_algorithm_t* pk_algos, int pk_algos_length,
gnutls_retr_st* st);
   *
-  * @st should contain the certificates and private keys.
-  *
-  * @req_ca_cert, is only used in X.509 certificates.
+  * @req_ca_dn is only used in X.509 certificates.
   * Contains a list with the CA names that the server considers trusted.
   * Normally we should send a certificate that is signed
   * by one of these CAs. These names are DER encoded. To get a more
   * meaningful value use the function gnutls_x509_rdn_get().
   *
-  * @pk_algos, contains a list with server's acceptable signature algorithms.
+  * @pk_algos contains a list with server's acceptable signature algorithms.
   * The certificate returned should support the server's given algorithms.
   *
+  * @st should contain the certificates and private keys.
+  *
   * If the callback function is provided then gnutls will call it, in the
   * handshake, after the certificate request message has been received.
   *
--
1.5.3.GIT



From nmav at gnutls.org  Sun Nov 11 07:27:53 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 11 Nov 2007 08:27:53 +0200
Subject: [gnutls-dev] gnutls_certificate_send_x509_rdn_sequence not
	exposed
In-Reply-To: <3a6f89fc0711101819w16c52cebq9a97e84475e77797@mail.gmail.com>
References: <3a6f89fc0711101627y58a351acx1e2573e1689ddffd@mail.gmail.com>
	<3a6f89fc0711101818v6bc70564xc1e8b173895285d@mail.gmail.com>
	<3a6f89fc0711101819w16c52cebq9a97e84475e77797@mail.gmail.com>
Message-ID: <200711110827.53867.nmav@gnutls.org>

On Sunday 11 November 2007, Evan Martin wrote:
> The documentation refers to a function called
> gnutls_certificate_send_x509_rdn_sequence(), but it's not public in
> any header.
> Is this intentional or an oversight?

It was an oversight and is now fixed. Thank you for all the suggestions and
patches.

regards,
Nikos



From tim.kosse at filezilla-project.org  Tue Nov 13 16:47:08 2007
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Tue, 13 Nov 2007 16:47:08 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
Message-ID: <4739C6FC.5000709@filezilla-project.org>

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

I've got several reports of failing connections with
GNUTLS_E_INTERNAL_ERROR.

I could track this problem down to the end of
_gnutls_ciphertext2compressed in gnutls_cipher.cpp:

if (compress_size < length) return GNUTLS_E_INTERNAL_ERROR

In all these cases, compress_size was 16284. Length was slightly larger
by various amounts. For example 16394 was a value I could frequently
observe.

I've noticed that in get_temp_recv_buffer, the buffer gets allocated
with MAX_RECORD_RECV_SIZE bytes.

_gnutls_decompress in gnutls_compress_int.c however checks for
(compress_size > max_record_size + EXTRA_COMP_SIZE).

So shouldn't get_temp_recv_buffer allocate MAX_RECORD_RECV_SIZE +
EXTRA_COMP_SIZE?

Doing so fixed this issue in my case, though I've no idea if that's proper.

Regards,
Tim Kosse
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOcb88N9+lcqiUkURAvppAJ9E87LPMXsQeHfg2i+SW1RB99NoAACg9oxP
i0jT/tXSl+Sv1wgC6ai/QkA=
=mgHk
-----END PGP SIGNATURE-----



From nmav at gnutls.org  Tue Nov 13 20:53:16 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Nov 2007 21:53:16 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <4739C6FC.5000709@filezilla-project.org>
References: <4739C6FC.5000709@filezilla-project.org>
Message-ID: <200711132153.17124.nmav@gnutls.org>

On Tuesday 13 November 2007, Tim Kosse wrote:
> I've got several reports of failing connections with
> GNUTLS_E_INTERNAL_ERROR.
>
> I could track this problem down to the end of
> _gnutls_ciphertext2compressed in gnutls_cipher.cpp:
>
> if (compress_size < length) return GNUTLS_E_INTERNAL_ERROR
>
> In all these cases, compress_size was 16284. Length was slightly larger

Do you mean 16384 instead?

> by various amounts. For example 16394 was a value I could frequently
> observe.

Well... If I understand correctly your compressed data decompressed to 
something over 2^14.  This is not allowed by the TLS 1.0 spec and this
is the reason you see this error. Are you using gnutls for both peers? 
Which version?


regards,
Nikos



From simon at josefsson.org  Wed Nov 14 17:13:21 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 14 Nov 2007 17:13:21 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
Message-ID: <871wasbyam.fsf@mocca.josefsson.org>

I'll roll a gnutls 2.2 release candidate within a few days, and I'm
starting to prepare the release notes for the final release.  Since we
are breaking the API/ABI version, we need careful documentation.

Here is a starting point, based on a 'diff -ru' of includes/ between
latest 2.0 and 2.1.  What have I missed?  Other thoughts?  Please let me
know what you think.  Language fixes are very appreciated, English isn't
my strong subject...  Thoughts on the gnutls_set_default_priority change
are also appreciated.

/Simon

API changes in GnuTLS 2.2
=========================

To adapt to changes in the TLS extension specifications for OpenPGP and
SRP, the GnuTLS API had to be modified.  Since we had to modify the API,
we decided to do some long pending API cleanups as well.  Generally,
most applications do not need to be modified.  Just re-compile it
against the latest GnuTLS release should work.  However, applications
that use the OpenPGP or SRP features needs to be modified.  Below is a
list of the modified APIs and discussion of what you need to modify in
your application.

General changes
---------------

The functions `gnutls_set_default_priority',
`gnutls_set_default_export_priority' have been replaced by
`gnutls_set_default_priority2'.  There are compatibility mappings from
the old names to the new.  (XXX: do we really need to do this?  Seems
frivolous to me, at least `gnutls_set_default_priority' is very common,
and could be kept around and supported in the future.)

The function `gnutls_x509_crt_to_xml' was removed, it has not done
anything (except returning an error code) since around GnuTLS 1.2.
Nobody has complained, so users doesn't seem to miss the functionality.
We don't know of any libraries to convert X.509 certificates into XML
format, but we decided (long ago) that GnuTLS isn't the right place for
this kind of functionality.

SRP related changes
-------------------

The callback gnutls_srp_client_credentials_function has a new prototype,
and its semantic has changed.  You need to rewrite the callback, see the
updated function documentation and examples for more information.

The alert codes GNUTLS_A_MISSING_SRP_USERNAME and
GNUTLS_A_UNKNOWN_SRP_USERNAME are no longer used by the SRP
specification, instead the GNUTLS_A_UNKNOWN_PSK_IDENTITY alert should be
used.  There are #define's to map the old names to the new.

OpenPGP related changes
-----------------------

The functions `gnutls_certificate_set_openpgp_key_file',
`gnutls_certificate_set_openpgp_key_mem',
`gnutls_certificate_set_openpgp_keyring_mem', and
`gnutls_certificate_set_openpgp_keyring_file' has an added parameter of
the (new) type `gnutls_openpgp_crt_fmt_t'.  The type specify the format
of the data (binary or base64).

The function `gnutls_certificate_set_openpgp_keyserver' have been
removed.  There is no replacement functionality inside GnuTLS.  If you
need keyserver functionality, consider using the GnuPG tools.

All functions related to OpenPGP trustdb format have been removed, since
the trustdb was a non-standard GnuPG-specific format.  Use key rings
instead.  The removed functions and types are:

 gnutls_certificate_set_openpgp_trustdb
 gnutls_openpgp_trustdb_init
 gnutls_openpgp_trustdb_deinit
 gnutls_openpgp_trustdb_import
 gnutls_openpgp_key_verify_trustdb
 gnutls_openpgp_trustdb_t
 GNUTLS_E_OPENPGP_TRUSTDB_VERSION_UNSUPPORTED

To align terminology, some functions or types have been renamed.
Compatibility mappings exists.  The old and new names of the affected
functions are:

        Old name                                New name
 gnutls_openpgp_key_init                 gnutls_openpgp_crt_init
 gnutls_openpgp_key_deinit               gnutls_openpgp_crt_deinit
 gnutls_openpgp_key_import               gnutls_openpgp_crt_import
 gnutls_openpgp_key_export               gnutls_openpgp_crt_export
 gnutls_openpgp_key_get_key_usage        gnutls_openpgp_crt_get_key_usage
 gnutls_openpgp_key_get_fingerprint      gnutls_openpgp_crt_get_fingerprint
 gnutls_openpgp_key_get_pk_algorithm     gnutls_openpgp_crt_get_pk_algorithm
 gnutls_openpgp_key_get_name             gnutls_openpgp_crt_get_name
 gnutls_openpgp_key_get_version          gnutls_openpgp_crt_get_version
 gnutls_openpgp_key_get_creation_time    gnutls_openpgp_crt_get_creation_time
 gnutls_openpgp_key_get_expiration_time  gnutls_openpgp_crt_get_expiration_time
 gnutls_openpgp_key_get_id               gnutls_openpgp_crt_get_id
 gnutls_openpgp_key_check_hostname       gnutls_openpgp_crt_check_hostname
 gnutls_openpgp_send_key                 gnutls_openpgp_send_cert
 gnutls_openpgp_key_status_t             gnutls_openpgp_crt_status_t
 GNUTLS_OPENPGP_KEY                      GNUTLS_OPENPGP_CERT
 GNUTLS_OPENPGP_KEY_FINGERPRINT          GNUTLS_OPENPGP_CERT_FINGERPRINT
 gnutls_openpgp_key_t                    gnutls_openpgp_crt_t



From ludovic.courtes at laas.fr  Wed Nov 14 18:03:49 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 14 Nov 2007 18:03:49 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org>
Message-ID: <876404g3nu.fsf@laas.fr>

Hi,

Tim Kosse <tim.kosse at filezilla-project.org> writes:

> I've got several reports of failing connections with
> GNUTLS_E_INTERNAL_ERROR.
>
> I could track this problem down to the end of
> _gnutls_ciphertext2compressed in gnutls_cipher.cpp:
>
> if (compress_size < length) return GNUTLS_E_INTERNAL_ERROR

FWIW, I came across the very same problem (I'm using OpenPGP
authentication) and am currently investigating...

Thanks,
Ludovic.




From ametzler at downhill.at.eu.org  Wed Nov 14 19:08:09 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 14 Nov 2007 19:08:09 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <871wasbyam.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
Message-ID: <20071114180809.GA4994@downhill.g.la>

On 2007-11-14 Simon Josefsson <simon at josefsson.org> wrote:
> I'll roll a gnutls 2.2 release candidate within a few days, and I'm
> starting to prepare the release notes for the final release.  Since we
> are breaking the API/ABI version, we need careful documentation.

> Here is a starting point, based on a 'diff -ru' of includes/ between
> latest 2.0 and 2.1.

The "latest 2.0.x" was 2.0.2, however afaik it was not a stable
release (it also broke the API).

> What have I missed? 
[...]

GNUTLS_E_UNKNOWN_HASH_ALGORITHM has also been removed/mapped to
GNUTLS_E_INTERNAL_ERROR.
cu and- http://bugs.debian.org/450854 -reas
-- 
`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  Thu Nov 15 09:23:03 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 Nov 2007 09:23:03 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <20071114180809.GA4994@downhill.g.la> (Andreas Metzler's message
	of "Wed, 14 Nov 2007 19:08:09 +0100")
References: <871wasbyam.fsf@mocca.josefsson.org>
	<20071114180809.GA4994@downhill.g.la>
Message-ID: <87ve833ok8.fsf@mocca.josefsson.org>

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

> On 2007-11-14 Simon Josefsson <simon at josefsson.org> wrote:
>> I'll roll a gnutls 2.2 release candidate within a few days, and I'm
>> starting to prepare the release notes for the final release.  Since we
>> are breaking the API/ABI version, we need careful documentation.
>
>> Here is a starting point, based on a 'diff -ru' of includes/ between
>> latest 2.0 and 2.1.
>
> The "latest 2.0.x" was 2.0.2, however afaik it was not a stable
> release (it also broke the API).

2.0.3 actually, but it only added APIs.  It is considered (at least by
me) a stable release.  Why does adding APIs cause problems?

>> What have I missed? 
> [...]
>
> GNUTLS_E_UNKNOWN_HASH_ALGORITHM has also been removed/mapped to
> GNUTLS_E_INTERNAL_ERROR.
> cu and- http://bugs.debian.org/450854 -reas

Thanks, I'll revert this change since it causes problems.

Thanks,
Simon



From ludo at gnu.org  Thu Nov 15 10:07:19 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 15 Nov 2007 10:07:19 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org>
	<200711132153.17124.nmav@gnutls.org>
Message-ID: <87oddvyj08.fsf@chbouib.org>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Well... If I understand correctly your compressed data decompressed to 
> something over 2^14.  This is not allowed by the TLS 1.0 spec and this
> is the reason you see this error. Are you using gnutls for both peers? 
> Which version?

For me, it's 2.0.1 as found in Debian.  Note that it fails equally well
when using the `NULL' compression method, so the issue is probably not
related to compression.

Unfortunately, I'm unable to provide a simple test case that reproduces
the problem.  My setup involves at least one Nokia N770/N800 device (an
ARMEL thingie).  Running the same code (client + server) on x86 doesn't
yield any error.

Thanks,
Ludovic.




From nmav at gnutls.org  Thu Nov 15 09:16:25 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 10:16:25 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <876404g3nu.fsf@laas.fr>
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
Message-ID: <c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>

I think I've solved it in the git repository. Could you check if my changes
solve the problem for you? (you can check the gnutls_2_0_x branch for the
stable patch).

regards,
Nikos

On Nov 14, 2007 7:03 PM, Ludovic Court?s <ludovic.courtes at laas.fr> wrote:
> Hi,
>
> Tim Kosse <tim.kosse at filezilla-project.org> writes:
>
> > I've got several reports of failing connections with
> > GNUTLS_E_INTERNAL_ERROR.
> >
> > I could track this problem down to the end of
> > _gnutls_ciphertext2compressed in gnutls_cipher.cpp:
> >
> > if (compress_size < length) return GNUTLS_E_INTERNAL_ERROR
>
> FWIW, I came across the very same problem (I'm using OpenPGP
> authentication) and am currently investigating...
>
> Thanks,
> Ludovic.
>
>
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>



From simon at josefsson.org  Thu Nov 15 10:01:26 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 Nov 2007 10:01:26 +0100
Subject: [gnutls-dev] GnuTLS 2.1.6
Message-ID: <87k5oj3ms9.fsf@mocca.josefsson.org>

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

News in this release:

* Version 2.1.6 (released 2007-11-15)

** Corrected bug in decompression of expanded compression data.

** Added the --to-p8 option to certtool to convert private keys
to PKCS #8 keys.

** Introduced the GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR error code.

** gnutls_certificate_set_x509_key_* can now read PKCS #8 unencrypted
private keys.

** Fixed GNUTLS_E_UNKNOWN_ALGORITHM vs GNUTLS_E_UNKNOWN_HASH_ALGORITHM.
During the 2.1.x series the GNUTLS_E_UNKNOWN_HASH_ALGORITHM error code
was renamed to GNUTLS_E_UNKNOWN_ALGORITHM, unfortunately without being
documented.  This caused some problems (e.g., debian #450854).  To
avoid backwards compatibility problems, this release revert this
change, so that GNUTLS_E_UNKNOWN_HASH_ALGORITHM works just like it has
done in GnuTLS 2.0.x and earlier, and add a new error code
GNUTLS_E_UNKNOWN_ALGORITHM.

** Fixes several gtk-doc warnings.

** API and ABI modifications:
GNUTLS_E_UNKNOWN_ALGORITHM: CHANGED.
GNUTLS_E_UNKNOWN_HASH_ALGORITHM: CHANGED.
GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR: ADD.

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

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

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.6.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.1.6.tar.bz2

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

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

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

From simon at josefsson.org  Thu Nov 15 11:03:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 Nov 2007 11:03:17 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87ve833ok8.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 15 Nov 2007 09:23:03 +0100")
References: <871wasbyam.fsf@mocca.josefsson.org>
	<20071114180809.GA4994@downhill.g.la>
	<87ve833ok8.fsf@mocca.josefsson.org>
Message-ID: <87wssj25cq.fsf@mocca.josefsson.org>

Updated release notes wrt to the API/ABI changes below.

After consideration, I believe we should revert the change to deprecate
gnutls_set_default_priority().  It is a widely used function and
gnutls_set_default_priority2() doesn't offer any significant difference
for most applications.  I think people will think that we just change
the API for no reason if we make this change.  What do others think?
Nikos is this ok with you?

Further, I believe we could improve the gnutls_set_default_priority2()
API.  Right now it is difficult to use from applications.  Each
application would need to have a configuration file token (e.g.,
'gnutls-priority: EXPORT') or command line parameter (e.g.,
--gnutls-priority PERFORMANCE) that map to the GnuTLS enum types.  A
serious problem is that there would be no consistency between GnuTLS
applications on what the enum names should be and their meaning.

I think it would be better if we had a function like:

  int gnutls_set_priority (gnutls_session_t session,
                           const char *priority);

It would take strings that can be set by users in application
configuration files or command line parameters.  GnuTLS could define a
couple of strings:

  DEFAULT
  EXPORT
  PERFORMANCE
  SECURITY

etc.  Eventually we could even support something like OpenSSL's priority
strings, which allow things similar to 'DEFAULT:-AES' to use the
defaults, but remove all AES ciphers.

This interface seems more flexible than the
gnutls_set_default_priority2() interface.

Thoughts?  Nikos?

/Simon

API changes in GnuTLS 2.2
=========================

To adapt to changes in the TLS extension specifications for OpenPGP
and SRP, the GnuTLS API had to be modified.  Since we had to modify
the API, we decided to do some long pending API cleanups as well.
Generally, most applications do not need to be modified.  Just
re-compile it against the latest GnuTLS release should work.  However,
applications that use the OpenPGP or SRP features needs to be
modified.  Below is a list of the modified APIs and discussion of what
you need to modify in your application.

General changes
---------------

The functions `gnutls_set_default_priority',
`gnutls_set_default_export_priority' have been replaced by
`gnutls_set_default_priority2'.  There are compatibility mappings from
the old names to the new.  (XXX: do we really need to do this?  Seems
frivolous to me, at least `gnutls_set_default_priority' is very common,
and could be kept around and supported in the future.)

The function `gnutls_x509_crt_to_xml' was removed, it has not done
anything (except returning an error code) since around GnuTLS 1.2.
Nobody has complained, so users doesn't seem to miss the
functionality.  We don't know of any libraries to convert X.509
certificates into XML format, but we decided (long ago) that GnuTLS
isn't the right place for this kind of functionality.

SRP related changes
-------------------

The callback gnutls_srp_client_credentials_function has a new
prototype, and its semantic has changed.  You need to rewrite the
callback, see the updated function documentation and examples for more
information.

The alert codes GNUTLS_A_MISSING_SRP_USERNAME and
GNUTLS_A_UNKNOWN_SRP_USERNAME are no longer used by the SRP
specification, instead the GNUTLS_A_UNKNOWN_PSK_IDENTITY alert should
be used.  There are #define's to map the old names to the new.

OpenPGP related changes
-----------------------

The functions `gnutls_certificate_set_openpgp_key_file',
`gnutls_certificate_set_openpgp_key_mem',
`gnutls_certificate_set_openpgp_keyring_mem', and
`gnutls_certificate_set_openpgp_keyring_file' has an added parameter
of the (new) type `gnutls_openpgp_crt_fmt_t'.  The type specify the
format of the data (binary or base64).

The function `gnutls_certificate_set_openpgp_keyserver' have been
removed.  There is no replacement functionality inside GnuTLS.  If you
need keyserver functionality, consider using the GnuPG tools.

All functions, types, and error codes related to OpenPGP trustdb
format have been removed.  The trustdb format is a non-standard
GnuPG-specific format, and we recommend you to use key rings instead.
The following have been removed:

 gnutls_certificate_set_openpgp_trustdb
 gnutls_openpgp_trustdb_init
 gnutls_openpgp_trustdb_deinit
 gnutls_openpgp_trustdb_import
 gnutls_openpgp_key_verify_trustdb
 gnutls_openpgp_trustdb_t
 GNUTLS_E_OPENPGP_TRUSTDB_VERSION_UNSUPPORTED

To improve terminology and align with the X.509 interface, some
functions have been renamed.  Compatibility mappings exists.  The old
and new names of the affected functions and types are:

        Old name                                New name
 gnutls_openpgp_key_init                 gnutls_openpgp_crt_init
 gnutls_openpgp_key_deinit               gnutls_openpgp_crt_deinit
 gnutls_openpgp_key_import               gnutls_openpgp_crt_import
 gnutls_openpgp_key_export               gnutls_openpgp_crt_export
 gnutls_openpgp_key_get_key_usage        gnutls_openpgp_crt_get_key_usage
 gnutls_openpgp_key_get_fingerprint      gnutls_openpgp_crt_get_fingerprint
 gnutls_openpgp_key_get_pk_algorithm     gnutls_openpgp_crt_get_pk_algorithm
 gnutls_openpgp_key_get_name             gnutls_openpgp_crt_get_name
 gnutls_openpgp_key_get_version          gnutls_openpgp_crt_get_version
 gnutls_openpgp_key_get_creation_time    gnutls_openpgp_crt_get_creation_time
 gnutls_openpgp_key_get_expiration_time  gnutls_openpgp_crt_get_expiration_time
 gnutls_openpgp_key_get_id               gnutls_openpgp_crt_get_id
 gnutls_openpgp_key_check_hostname       gnutls_openpgp_crt_check_hostname
 gnutls_openpgp_send_key                 gnutls_openpgp_send_cert
 gnutls_openpgp_key_status_t             gnutls_openpgp_crt_status_t
 GNUTLS_OPENPGP_KEY                      GNUTLS_OPENPGP_CERT
 GNUTLS_OPENPGP_KEY_FINGERPRINT          GNUTLS_OPENPGP_CERT_FINGERPRINT
 gnutls_openpgp_key_t                    gnutls_openpgp_crt_t



From n.mavrogiannopoulos at gmail.com  Thu Nov 15 10:59:41 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 11:59:41 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <87oddvyj08.fsf@chbouib.org>
References: <4739C6FC.5000709@filezilla-project.org>
	<200711132153.17124.nmav@gnutls.org> <87oddvyj08.fsf@chbouib.org>
Message-ID: <c331d99a0711150159l77fdf7d6td7c8b8b0dbe48503@mail.gmail.com>

There was a fix for some mobile clients in 2.0.3 and the latest development
release (solved by the gnutls_set_compaitiblity_mode() ) function. Are
you sure you are
not experiencing this problem?

On Nov 15, 2007 11:07 AM, Ludovic Court?s <ludo at gnu.org> wrote:
> Hi,
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
> > Well... If I understand correctly your compressed data decompressed to
> > something over 2^14.  This is not allowed by the TLS 1.0 spec and this
> > is the reason you see this error. Are you using gnutls for both peers?
> > Which version?
>
> For me, it's 2.0.1 as found in Debian.  Note that it fails equally well
> when using the `NULL' compression method, so the issue is probably not
> related to compression.
>
> Unfortunately, I'm unable to provide a simple test case that reproduces
> the problem.  My setup involves at least one Nokia N770/N800 device (an
> ARMEL thingie).  Running the same code (client + server) on x86 doesn't
> yield any error.
>
> Thanks,
> Ludovic.



From ludovic.courtes at laas.fr  Thu Nov 15 14:27:10 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 15 Nov 2007 14:27:10 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
	<c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>
Message-ID: <87abpf8wr5.fsf@laas.fr>

Hi,

"Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:

> I think I've solved it in the git repository. Could you check if my changes
> solve the problem for you? (you can check the gnutls_2_0_x branch for the
> stable patch).

I can't directly switch to 2.0.3, so I used 2.0.1 with the attached
patch (your last 2 commits on the `gnutls_2_0_x' branch).

Unfortunately, that doesn't fix the problem: I'm still getting a
`_gnutls_decrypt ()' failure (`GNUTLS_E_DECRYPTION_FAILED' this time) at
`gnutls_record.c:988'.

Again, I'm using the `NULL' compression method.

Thanks,
Ludovic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16_compression-fix.diff
Type: text/x-patch
Size: 4651 bytes
Desc: The patch
URL: </pipermail/attachments/20071115/74a418d7/attachment.bin>

From ludovic.courtes at laas.fr  Thu Nov 15 14:28:24 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 15 Nov 2007 14:28:24 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org>
	<200711132153.17124.nmav@gnutls.org> <87oddvyj08.fsf@chbouib.org>
	<c331d99a0711150159l77fdf7d6td7c8b8b0dbe48503@mail.gmail.com>
Message-ID: <873av78wp3.fsf@laas.fr>

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

> There was a fix for some mobile clients in 2.0.3 and the latest development
> release (solved by the gnutls_set_compaitiblity_mode() ) function. Are
> you sure you are
> not experiencing this problem?

Sorry, what are you referring to?  I don't remember reading anything
like this and the Git log on `gnutls_2_0_x' doesn't help either.

Thanks,
Ludovic.




From ludovic.courtes at laas.fr  Thu Nov 15 15:06:27 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 15 Nov 2007 15:06:27 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
	<c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>
Message-ID: <87abpf7gd8.fsf@laas.fr>

With the attached patch against 2.0.1 (your 2 fixes + additional
`gnutls?assert's) and `NULL' encryption, I nailed it down to this part
of `gnutls_cipher.c':

  /* This one was introduced to avoid a timing attack against the TLS
   * 1.0 protocol.
   */
  if (pad_failed != 0)
    {
      gnutls_assert (); /* <-- This is where we fail */
      return pad_failed;
    }

That's the first `assert' I see, which seems to indicate that PAD_FAILED
was set here:

   /* Check the pading bytes (TLS 1.x)
    */
   if (ver >= GNUTLS_TLS1 && pad_failed == 0)
     for (i = 2; i < pad; i++)
       {
         if (ciphertext.data[ciphertext.size - i] !=
             ciphertext.data[ciphertext.size - 1])
           pad_failed = GNUTLS_E_DECRYPTION_FAILED;
       }

It's pretty hard for me to debug this on a Nokia so I hope you'll come
up with a bright idea.  :-)

Thanks,
Ludovic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,,maemo.diff
Type: text/x-patch
Size: 5612 bytes
Desc: The patch
URL: </pipermail/attachments/20071115/a43a99cf/attachment.bin>

From n.mavrogiannopoulos at gmail.com  Thu Nov 15 15:21:46 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 16:21:46 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <87abpf7gd8.fsf@laas.fr>
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
	<c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>
	<87abpf7gd8.fsf@laas.fr>
Message-ID: <c331d99a0711150621w75d39cd6lcd8356000b6e85e3@mail.gmail.com>

I was talking about this patch (quite big):
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=a923cc605a40cf73dbb40de0ac46978674e388fd
and use gnutls_session_enable_compatibility_mode() on your server.

On Nov 15, 2007 4:06 PM, Ludovic Court?s <ludovic.courtes at laas.fr> wrote:
> With the attached patch against 2.0.1 (your 2 fixes + additional
> `gnutlsassert's) and `NULL' encryption, I nailed it down to this part
> of `gnutls_cipher.c':
>
>   /* This one was introduced to avoid a timing attack against the TLS
>    * 1.0 protocol.
>    */
>   if (pad_failed != 0)
>     {
>       gnutls_assert (); /* <-- This is where we fail */
>       return pad_failed;
>     }
>
> That's the first `assert' I see, which seems to indicate that PAD_FAILED
> was set here:
>
>    /* Check the pading bytes (TLS 1.x)
>     */
>    if (ver >= GNUTLS_TLS1 && pad_failed == 0)
>      for (i = 2; i < pad; i++)
>        {
>          if (ciphertext.data[ciphertext.size - i] !=
>              ciphertext.data[ciphertext.size - 1])
>            pad_failed = GNUTLS_E_DECRYPTION_FAILED;
>        }
>
> It's pretty hard for me to debug this on a Nokia so I hope you'll come
> up with a bright idea.  :-)
>
> Thanks,
> Ludovic.
>
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev
>
>



From n.mavrogiannopoulos at gmail.com  Thu Nov 15 15:32:24 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 16:32:24 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <c331d99a0711150621w75d39cd6lcd8356000b6e85e3@mail.gmail.com>
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
	<c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>
	<87abpf7gd8.fsf@laas.fr>
	<c331d99a0711150621w75d39cd6lcd8356000b6e85e3@mail.gmail.com>
Message-ID: <c331d99a0711150632j7a10de66q9b9448b0088a149d@mail.gmail.com>

Or if you just want a quick and dirty fix for your copy in gnutls_record.c
at the call _gnutls_encrypt() the last parameter is 1. Just turn it to
zero (disables random padding).

regards,
Nikos

On Nov 15, 2007 4:21 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> I was talking about this patch (quite big):
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=a923cc605a40cf73dbb40de0ac46978674e388fd
> and use gnutls_session_enable_compatibility_mode() on your server.
>
> On Nov 15, 2007 4:06 PM, Ludovic Court?s <ludovic.courtes at laas.fr> wrote:
> > With the attached patch against 2.0.1 (your 2 fixes + additional
> > `gnutlsassert's) and `NULL' encryption, I nailed it down to this part
>
> > of `gnutls_cipher.c':
> >
> >   /* This one was introduced to avoid a timing attack against the TLS
> >    * 1.0 protocol.
> >    */
> >   if (pad_failed != 0)
> >     {
> >       gnutls_assert (); /* <-- This is where we fail */
> >       return pad_failed;
> >     }
> >
> > That's the first `assert' I see, which seems to indicate that PAD_FAILED
> > was set here:
> >
> >    /* Check the pading bytes (TLS 1.x)
> >     */
> >    if (ver >= GNUTLS_TLS1 && pad_failed == 0)
> >      for (i = 2; i < pad; i++)
> >        {
> >          if (ciphertext.data[ciphertext.size - i] !=
> >              ciphertext.data[ciphertext.size - 1])
> >            pad_failed = GNUTLS_E_DECRYPTION_FAILED;
> >        }
> >
> > It's pretty hard for me to debug this on a Nokia so I hope you'll come
> > up with a bright idea.  :-)
> >
> > Thanks,
> > Ludovic.
> >
> >
>
> > _______________________________________________
> > Gnutls-dev mailing list
> > Gnutls-dev at gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnutls-dev
> >
> >
>



From ludovic.courtes at laas.fr  Thu Nov 15 15:40:58 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 15 Nov 2007 15:40:58 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org> <876404g3nu.fsf@laas.fr>
	<c331d99a0711150016g26b8d87kbe91e3144dfd5d17@mail.gmail.com>
	<87abpf7gd8.fsf@laas.fr>
	<c331d99a0711150621w75d39cd6lcd8356000b6e85e3@mail.gmail.com>
	<c331d99a0711150632j7a10de66q9b9448b0088a149d@mail.gmail.com>
Message-ID: <87y7cz6079.fsf@laas.fr>

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

> Or if you just want a quick and dirty fix for your copy in gnutls_record.c
> at the call _gnutls_encrypt() the last parameter is 1. Just turn it to
> zero (disables random padding).

Did that but it doesn't make any difference.

Thanks,
Ludovic.




From ametzler at downhill.at.eu.org  Thu Nov 15 19:08:00 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 15 Nov 2007 19:08:00 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87ve833ok8.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<20071114180809.GA4994@downhill.g.la>
	<87ve833ok8.fsf@mocca.josefsson.org>
Message-ID: <20071115180800.GA5002@downhill.g.la>

On 2007-11-15 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
>> The "latest 2.0.x" was 2.0.2, however afaik it was not a stable
>> release (it also broke the API).

> 2.0.3 actually, but it only added APIs.  It is considered (at least by
> me) a stable release.  Why does adding APIs cause problems?

I was mistaken _and_ I missed the 2.0.3 announce. 2.0.2 did this

+** TLS authorization support removed.

but without breaking the ABI. Sorry for false alarm.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From nmav at gnutls.org  Thu Nov 15 21:01:48 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 22:01:48 +0200
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87wssj25cq.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<87ve833ok8.fsf@mocca.josefsson.org>
	<87wssj25cq.fsf@mocca.josefsson.org>
Message-ID: <200711152201.48510.nmav@gnutls.org>

On Thursday 15 November 2007, Simon Josefsson wrote:

> Updated release notes wrt to the API/ABI changes below.
>
> After consideration, I believe we should revert the change to deprecate
> gnutls_set_default_priority().  It is a widely used function and
> gnutls_set_default_priority2() doesn't offer any significant difference
> for most applications.  I think people will think that we just change
> the API for no reason if we make this change.  What do others think?
> Nikos is this ok with you?
> Further, I believe we could improve the gnutls_set_default_priority2()
> API.  Right now it is difficult to use from applications.  Each
> application would need to have a configuration file token (e.g.,
> 'gnutls-priority: EXPORT') or command line parameter (e.g.,
> --gnutls-priority PERFORMANCE) that map to the GnuTLS enum types.  A
> serious problem is that there would be no consistency between GnuTLS
> applications on what the enum names should be and their meaning.
>
> I think it would be better if we had a function like:
>
>   int gnutls_set_priority (gnutls_session_t session,
>                            const char *priority);

This has the problem of having to parse strings. But anyway it is a step 
forward.


regards,
Nikos



From nmav at gnutls.org  Thu Nov 15 21:04:48 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 Nov 2007 22:04:48 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <87y7cz6079.fsf@laas.fr>
References: <4739C6FC.5000709@filezilla-project.org>
	<c331d99a0711150632j7a10de66q9b9448b0088a149d@mail.gmail.com>
	<87y7cz6079.fsf@laas.fr>
Message-ID: <200711152204.48730.nmav@gnutls.org>

On Thursday 15 November 2007, Ludovic Court?s wrote:
> "Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:
> > Or if you just want a quick and dirty fix for your copy in
> > gnutls_record.c at the call _gnutls_encrypt() the last parameter is 1.
> > Just turn it to zero (disables random padding).
>
> Did that but it doesn't make any difference.

Then it might be another kind of bug. However I'd suggest that you try 
connecting to the most recent server (2.1.6). If that fails too could you
try different protocols (TLS 1.0 - SSL 3.0) and different algorithms (AES - 
ARCFOUR would be enough) at your connection and see which ones fail?

regards,
Nikos



From marlam at marlam.de  Thu Nov 15 20:14:52 2007
From: marlam at marlam.de (Martin Lambers)
Date: Thu, 15 Nov 2007 20:14:52 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87wssj25cq.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<20071114180809.GA4994@downhill.g.la>
	<87ve833ok8.fsf@mocca.josefsson.org>
	<87wssj25cq.fsf@mocca.josefsson.org>
Message-ID: <20071115191452.GA6769@wile.lambers.home>

On Thu, 15. Nov 2007, 11:03:17 +0100, Simon Josefsson wrote:
> Further, I believe we could improve the gnutls_set_default_priority2()
> API.  Right now it is difficult to use from applications.  Each
> application would need to have a configuration file token (e.g.,
> 'gnutls-priority: EXPORT') or command line parameter (e.g.,
> --gnutls-priority PERFORMANCE) that map to the GnuTLS enum types.  A
> serious problem is that there would be no consistency between GnuTLS
> applications on what the enum names should be and their meaning.
> 
> I think it would be better if we had a function like:
> 
>   int gnutls_set_priority (gnutls_session_t session,
>                            const char *priority);
> 
> It would take strings that can be set by users in application
> configuration files or command line parameters.  GnuTLS could define a
> couple of strings:
> 
>   DEFAULT
>   EXPORT
>   PERFORMANCE
>   SECURITY
> 
> etc.  Eventually we could even support something like OpenSSL's priority
> strings, which allow things similar to 'DEFAULT:-AES' to use the
> defaults, but remove all AES ciphers.

I think this is an excellent idea. Applications could give users the
possibility to tweak the priorities in a simple _and consistent_ way.
This would elegantly solve a current problem with msmtp and mpop; 
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 .

Martin



From simon at josefsson.org  Fri Nov 16 11:02:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Nov 2007 11:02:34 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <20071115191452.GA6769@wile.lambers.home> (Martin Lambers's
	message of "Thu, 15 Nov 2007 20:14:52 +0100")
References: <871wasbyam.fsf@mocca.josefsson.org>
	<20071114180809.GA4994@downhill.g.la>
	<87ve833ok8.fsf@mocca.josefsson.org>
	<87wssj25cq.fsf@mocca.josefsson.org>
	<20071115191452.GA6769@wile.lambers.home>
Message-ID: <87pryapkxx.fsf@mocca.josefsson.org>

Martin Lambers <marlam at marlam.de> writes:

> On Thu, 15. Nov 2007, 11:03:17 +0100, Simon Josefsson wrote:
>> Further, I believe we could improve the gnutls_set_default_priority2()
>> API.  Right now it is difficult to use from applications.  Each
>> application would need to have a configuration file token (e.g.,
>> 'gnutls-priority: EXPORT') or command line parameter (e.g.,
>> --gnutls-priority PERFORMANCE) that map to the GnuTLS enum types.  A
>> serious problem is that there would be no consistency between GnuTLS
>> applications on what the enum names should be and their meaning.
>> 
>> I think it would be better if we had a function like:
>> 
>>   int gnutls_set_priority (gnutls_session_t session,
>>                            const char *priority);
>> 
>> It would take strings that can be set by users in application
>> configuration files or command line parameters.  GnuTLS could define a
>> couple of strings:
>> 
>>   DEFAULT
>>   EXPORT
>>   PERFORMANCE
>>   SECURITY
>> 
>> etc.  Eventually we could even support something like OpenSSL's priority
>> strings, which allow things similar to 'DEFAULT:-AES' to use the
>> defaults, but remove all AES ciphers.
>
> I think this is an excellent idea. Applications could give users the
> possibility to tweak the priorities in a simple _and consistent_ way.
> This would elegantly solve a current problem with msmtp and mpop; 
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344 .

Interesting, it seems the set_priority function could do things related
to required diffie-hellman sizes too.  Possibly even the padding stuff.
It seems simpler than having applications have to do each call and
handle the user configuration stuff for each function; instead just have
one call in the application that forwards a string from the user which
can be interpreted by gnutls.

I'll implement this, but I'm going away on vacation later today, so
don't expect anything during next week.  If others have thoughts about
how the feature would work, please discuss it meanwhile.

/Simon



From ludovic.courtes at laas.fr  Fri Nov 16 17:45:13 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 16 Nov 2007 17:45:13 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org>
	<c331d99a0711150632j7a10de66q9b9448b0088a149d@mail.gmail.com>
	<87y7cz6079.fsf@laas.fr> <200711152204.48730.nmav@gnutls.org>
Message-ID: <87zlxe3zs6.fsf@laas.fr>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Then it might be another kind of bug. However I'd suggest that you try 
> connecting to the most recent server (2.1.6). If that fails too could you
> try different protocols (TLS 1.0 - SSL 3.0) and different algorithms (AES - 
> ARCFOUR would be enough) at your connection and see which ones fail?

It appears that `DHE_DSS_3DES_EDE_CBC_SHA1' works fine while
`DHE_DSS_AES_128_CBC_SHA1' doesn't ("Decryption failed" on the server
side right during handshake).  In both cases, this is TLS 1.1 (I tried
1.0 earlier but didn't notice any difference).

Unfortunately, I won't have time to investigate more for the time being.

Thanks,
Ludovic.




From simon at josefsson.org  Sat Nov 17 10:36:04 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 17 Nov 2007 10:36:04 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <87zlxe3zs6.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 16
	Nov 2007 17:45:13 +0100")
References: <4739C6FC.5000709@filezilla-project.org>
	<c331d99a0711150632j7a10de66q9b9448b0088a149d@mail.gmail.com>
	<87y7cz6079.fsf@laas.fr> <200711152204.48730.nmav@gnutls.org>
	<87zlxe3zs6.fsf@laas.fr>
Message-ID: <87k5ohfc3f.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> Then it might be another kind of bug. However I'd suggest that you try 
>> connecting to the most recent server (2.1.6). If that fails too could you
>> try different protocols (TLS 1.0 - SSL 3.0) and different algorithms (AES - 
>> ARCFOUR would be enough) at your connection and see which ones fail?
>
> It appears that `DHE_DSS_3DES_EDE_CBC_SHA1' works fine while
> `DHE_DSS_AES_128_CBC_SHA1' doesn't ("Decryption failed" on the server
> side right during handshake).  In both cases, this is TLS 1.1 (I tried
> 1.0 earlier but didn't notice any difference).
>
> Unfortunately, I won't have time to investigate more for the time being.

Is there anything to suggest that this behavior was introduced in the
2.1.x series?  I'm thinking something like that could held up our 2.2
release, but if the problem existed before, then it is not a new
problem.

/Simon



From simon at josefsson.org  Sat Nov 17 11:48:49 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 17 Nov 2007 11:48:49 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
Message-ID: <87k5ohdu5q.fsf@mocca.josefsson.org>

Hi!  Since I'm going away on vacation for one week, and the December 1th
date is approaching, I'm declaring that 2.1.6 should be considered a
release candidate for the version 2.2 release.  Please test it and post
here about any problems.

I think we should implement the string-based gnutls_set_priority
function, and revert the deprecation of gnutls_set_default_priority()
before the release, but that's the only thing except writing release
notes that I'm currently aware that could hold up the 2.2 release on
December 1th.

/Simon



From nmav at gnutls.org  Sat Nov 17 11:26:52 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 17 Nov 2007 12:26:52 +0200
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
In-Reply-To: <87zlxe3zs6.fsf@laas.fr>
References: <4739C6FC.5000709@filezilla-project.org>
	<200711152204.48730.nmav@gnutls.org> <87zlxe3zs6.fsf@laas.fr>
Message-ID: <200711171226.52697.nmav@gnutls.org>

On Friday 16 November 2007, Ludovic Court?s wrote:
> Hi,
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> > Then it might be another kind of bug. However I'd suggest that you try
> > connecting to the most recent server (2.1.6). If that fails too could you
> > try different protocols (TLS 1.0 - SSL 3.0) and different algorithms (AES
> > - ARCFOUR would be enough) at your connection and see which ones fail?
>
> It appears that `DHE_DSS_3DES_EDE_CBC_SHA1' works fine while
> `DHE_DSS_AES_128_CBC_SHA1' doesn't ("Decryption failed" on the server
> side right during handshake).  In both cases, this is TLS 1.1 (I tried
> 1.0 earlier but didn't notice any difference).
> Unfortunately, I won't have time to investigate more for the time being.

These are very similar ciphersuites and they only differ on the choice of AES 
instead of 3DES. I cannot imagine what this could cause the problem with the
provided information. (was compression used?)

regards,
Nikos



From nmav at gnutls.org  Sat Nov 17 15:33:21 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 17 Nov 2007 16:33:21 +0200
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87wssj25cq.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<87ve833ok8.fsf@mocca.josefsson.org>
	<87wssj25cq.fsf@mocca.josefsson.org>
Message-ID: <200711171633.22231.nmav@gnutls.org>

On Thursday 15 November 2007, Simon Josefsson wrote:

> I think it would be better if we had a function like:
>
>   int gnutls_set_priority (gnutls_session_t session,
>                            const char *priority);

I just remembered that there was a reason this priority function was kept 
simple from the begging (integers only). This function is called per session, 
thus having a parsing routing like this would add some overhead... This could 
be insignificant compared to RSA/DH etc, but still in a busy server it might 
become significant.

What I had thought then was to make this parsing routine output the result
in a gnutls_priority_st structure and then associate this struction with every 
session. If found that solution complex then...


regards,
Nikos



From simon at josefsson.org  Sun Nov 18 09:19:59 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 18 Nov 2007 09:19:59 +0100
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <200711171633.22231.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Sat, 17 Nov 2007 16:33:21 +0200")
References: <871wasbyam.fsf@mocca.josefsson.org>
	<87ve833ok8.fsf@mocca.josefsson.org>
	<87wssj25cq.fsf@mocca.josefsson.org>
	<200711171633.22231.nmav@gnutls.org>
Message-ID: <87abpcdky8.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Thursday 15 November 2007, Simon Josefsson wrote:
>
>> I think it would be better if we had a function like:
>>
>>   int gnutls_set_priority (gnutls_session_t session,
>>                            const char *priority);
>
> I just remembered that there was a reason this priority function was kept 
> simple from the begging (integers only). This function is called per session, 
> thus having a parsing routing like this would add some overhead... This could 
> be insignificant compared to RSA/DH etc, but still in a busy server it might 
> become significant.

Ah, I understand.

> What I had thought then was to make this parsing routine output the result
> in a gnutls_priority_st structure and then associate this struction with every 
> session. If found that solution complex then...

How about implementing the simple gnutls_set_priority function now, and
if it turns out that it is actually a performance bottle-neck for some
applications, we can add a gnutls_parse_priority and a new
gnutls_set_preparsed_priority function to handle that.  I think for 90 %
of the applications, the inefficiency doesn't matter.  Premature
optimization is the root of all evil etc...

/Simon



From nmav at gnutls.org  Sun Nov 18 14:42:06 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 18 Nov 2007 15:42:06 +0200
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87abpcdky8.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<200711171633.22231.nmav@gnutls.org>
	<87abpcdky8.fsf@mocca.josefsson.org>
Message-ID: <200711181542.06339.nmav@gnutls.org>

On Sunday 18 November 2007, Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> > On Thursday 15 November 2007, Simon Josefsson wrote:
> >> I think it would be better if we had a function like:
> >>
> >>   int gnutls_set_priority (gnutls_session_t session,
> >>                            const char *priority);
> >
> > I just remembered that there was a reason this priority function was kept
> > simple from the begging (integers only). This function is called per
> > session, thus having a parsing routing like this would add some
> > overhead... This could be insignificant compared to RSA/DH etc, but still
> > in a busy server it might become significant.
>
> Ah, I understand.
>
> > What I had thought then was to make this parsing routine output the
> > result in a gnutls_priority_st structure and then associate this
> > struction with every session. If found that solution complex then...
>
> How about implementing the simple gnutls_set_priority function now, and
> if it turns out that it is actually a performance bottle-neck for some
> applications, we can add a gnutls_parse_priority and a new
> gnutls_set_preparsed_priority function to handle that.  I think for 90 %
> of the applications, the inefficiency doesn't matter.  Premature
> optimization is the root of all evil etc...
Ok.

What about a parser that works like:

int
gnutls_set_default_priority2 (gnutls_session_t session, const char *priority, 
  char* syntax_error, size_t syntax_error_size)

  * Predefined sets of ciphersuites:
  * "PERFORMANCE" all the "secure" ciphersuites are enabled, 
  * limited to 128 bit ciphers and sorted by terms of speed performance.
  *
  * "NORMAL" option enables all "secure" ciphersuites 
  * limited to 128 bit ciphers and sorted by security margin.
  *
  * "HIGH" flag enables all "secure" ciphersuites 
  * including 256 bit ciphers and sorted by security margin.
  *
  * "EXPORT" all the ciphersuites are enabled, including
  * the low-security 40 bit ciphers.
  *
  * Special keywords:
  * '-' appended with an algorithm will remove this algorithm.
  * '%COMPAT' will enable compatibility features for a server.
  *

So one could specify something like:
"NORMAL:-AES-128-CBC", "PERFORMANCE:-ARCFOUR-128:-MD5:%COMPAT"

if we allow '+' it could also be "+AES-128-CBC:+ARCFOUR-128:+RSA:+SHA1:+MD5" 
(no predefined set is specified so it starts with an empty one).

About compression and versions as well as certificate types I was thinking 
something along:

"NORMAL:-VERS-TLS1.0:+VERS-TLS1.1:-AES-128-CBC:-COMP-DEFLATE:+CTYPE-OPENPGP"

If '-' conflicts with our internal separator visually we could also use '!' 
instead.


regards,
Nikos





From ametzler at downhill.at.eu.org  Sun Nov 18 15:55:46 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 18 Nov 2007 15:55:46 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <87k5ohdu5q.fsf@mocca.josefsson.org>
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
Message-ID: <20071118145546.GA4675@downhill.g.la>

On 2007-11-17 Simon Josefsson <simon at josefsson.org> wrote:
> Hi!  Since I'm going away on vacation for one week, and the December 1th
> date is approaching, I'm declaring that 2.1.6 should be considered a
> release candidate for the version 2.2 release.
[...]

Hello,

FWIW I have uploaded it to Debian experimental.

http://qa.debian.org/developer.php?login=pkg-gnutls-maint at lists.alioth.debian.org

It will probably not get a lot of testing there, but we'll see at
least whether autobuilding works.

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 mrsam at courier-mta.com  Sun Nov 18 22:12:25 2007
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 18 Nov 2007 16:12:25 -0500
Subject: [gnutls-dev] Symmetric cipher API
Message-ID: <cone.1195420345.490721.24664.500@commodore.email-scan.com>

Recently I converted some code that uses OpenSSL's EVP_CIPHER symmetric 
cipher API. I wrote a wrapper that mapped the following functions to their 
gcrypt equivalents: EVP_CIPHER_CTX_init(), EVP_CIPHER_CTX_cleanup(), 
EVP_(Encrypt|Decrypt)Init_ex(), EVP_(Encrypt|Decrypt)Update(), and 
EVP_(Encrypt|Decrypt)Final_ex().

If you are interested, I'll be happy to contribute this code. I also thought 
that it's better to make this a native libgcrypt API. This should be only a 
matter of renaming the function names and arguments to follow libgcrypt's 
naming conventions, and all the EVP function become now just some 
lightweight wrappers (or probably even macros).


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

From nmav at gnutls.org  Mon Nov 19 07:38:17 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 19 Nov 2007 08:38:17 +0200
Subject: [gnutls-dev] Symmetric cipher API
In-Reply-To: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
Message-ID: <200711190838.17890.nmav@gnutls.org>

On Sunday 18 November 2007, Sam Varshavchik wrote:
> Recently I converted some code that uses OpenSSL's EVP_CIPHER symmetric
> cipher API. I wrote a wrapper that mapped the following functions to their
> gcrypt equivalents: EVP_CIPHER_CTX_init(), EVP_CIPHER_CTX_cleanup(),
> EVP_(Encrypt|Decrypt)Init_ex(), EVP_(Encrypt|Decrypt)Update(), and
> EVP_(Encrypt|Decrypt)Final_ex().

We could always commit something like this to the openssl compatibility 
interface. However I don't understand its use. Why did you need such wrapper?

> If you are interested, I'll be happy to contribute this code. I also
> thought that it's better to make this a native libgcrypt API. This should
> be only a matter of renaming the function names and arguments to follow
> libgcrypt's naming conventions, and all the EVP function become now just
> some lightweight wrappers (or probably even macros).

Why do you think that it's better to have it as native libgcrypt API? What are 
the advantages of using this api comparing to libgcrypt's? As far as I 
understand the differences the libgcrypt's functions are safer, since you 
don't directly access structures, and the internals can be changed without
breaking binary compatibility.

regards,
Nikos



From ludovic.courtes at laas.fr  Mon Nov 19 10:23:59 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 19 Nov 2007 10:23:59 +0100
Subject: [gnutls-dev] GNUTLS_E_INTERNAL_ERROR in
	_gnutls_ciphertext2compressed
References: <4739C6FC.5000709@filezilla-project.org>
	<200711152204.48730.nmav@gnutls.org> <87zlxe3zs6.fsf@laas.fr>
	<200711171226.52697.nmav@gnutls.org>
Message-ID: <8763zy1tcg.fsf@laas.fr>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> instead of 3DES. I cannot imagine what this could cause the problem with the
> provided information. (was compression used?)

`NULL' compression.

Simon Josefsson <simon at josefsson.org> writes:

> Is there anything to suggest that this behavior was introduced in the
> 2.1.x series?

No, I'm using 2.0.1, plus the patches suggested by Nikos.

Thanks,
Ludovic.




From davefx at gmail.com  Mon Nov 19 11:17:54 2007
From: davefx at gmail.com (David =?ISO-8859-1?Q?Mar=EDn_Carre=F1o?=)
Date: Mon, 19 Nov 2007 11:17:54 +0100
Subject: [gnutls-dev] Lack of documented standard for exporting DSA
	priv_keys in PKCS8	format??
Message-ID: <1195467474.15058.11.camel@localhost>

Hi all.

I'm currently developing gnoMint[1], a program for graphically managing
a CA.

I've just realized that DSA private keys cannot be exported to PKCS8
format, "since there is no documented standard for other keys" than RSA,
according to the manual page.

However, in PKCS11 document[2], in page 248 (section 12.6), it is said
how to wrap and unwrap, among others, DSA private keys, in PKCS#8?s
PrivateKeyInfo ASN.1 type.

I don't know if this can be considered a "documented standard", but I
think it is.

[1] http://gnomint.sf.net
[2] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a3.pdf

Greetings.

-- 
David Mar?n Carre?o <davefx at gmail.com>




From mrsam at courier-mta.com  Mon Nov 19 13:14:02 2007
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 19 Nov 2007 07:14:02 -0500
Subject: [gnutls-dev] Symmetric cipher API
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
	<200711190838.17890.nmav@gnutls.org>
Message-ID: <cone.1195474442.570650.12944.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> On Sunday 18 November 2007, Sam Varshavchik wrote:
>> Recently I converted some code that uses OpenSSL's EVP_CIPHER symmetric
>> cipher API. I wrote a wrapper that mapped the following functions to their
>> gcrypt equivalents: EVP_CIPHER_CTX_init(), EVP_CIPHER_CTX_cleanup(),
>> EVP_(Encrypt|Decrypt)Init_ex(), EVP_(Encrypt|Decrypt)Update(), and
>> EVP_(Encrypt|Decrypt)Final_ex().
> 
> We could always commit something like this to the openssl compatibility 
> interface. However I don't understand its use. Why did you need such wrapper?

Because I have existing OpenSSL-based code that uses this API, and there is 
nothing in libgcrypt that maps exactly to it.

>> If you are interested, I'll be happy to contribute this code. I also
>> thought that it's better to make this a native libgcrypt API. This should
>> be only a matter of renaming the function names and arguments to follow
>> libgcrypt's naming conventions, and all the EVP function become now just
>> some lightweight wrappers (or probably even macros).
> 
> Why do you think that it's better to have it as native libgcrypt API? What are 
> the advantages of using this api comparing to libgcrypt's? As far as I 
> understand the differences the libgcrypt's functions are safer, since you 
> don't directly access structures, and the internals can be changed without
> breaking binary compatibility.

The wrapper code also uses only the existing published libgcrypt APIs as 
well. Think of it as a higher-level API that sits on top of 
gcry_cipher_encrypt and gcry_cipher_decrypt. This OpenSSL API is for 
symmetric block ciphers, but the application does not have to have to supply 
the input as block-sized chunks. The application supplies the input 
piece-meal, as an arbitrary data stream, and the EVP functions take care of 
carving it up into block-sized chunks and feeding each chunk to the cipher 
function. Finally, the EVP functions take care of PKCS padding, so the 
application's encrypted/decrypted data stream does not have to be a multiple 
of the block size.

>From an application's standpoint, this API is much more convenient than just 
gcry_cipher_encrypt and gcry_cipher_decrypt. There's far less low-level 
detail to worry about.

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

From wk at gnupg.org  Mon Nov 19 14:33:11 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Nov 2007 14:33:11 +0100
Subject: [gnutls-dev] Symmetric cipher API
In-Reply-To: <cone.1195474442.570650.12944.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Mon, 19 Nov 2007 07:14:02 -0500")
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
	<200711190838.17890.nmav@gnutls.org>
	<cone.1195474442.570650.12944.500@commodore.email-scan.com>
Message-ID: <87bq9qqs14.fsf@wheatstone.g10code.de>

On Mon, 19 Nov 2007 13:14, mrsam at courier-mta.com said:

> input piece-meal, as an arbitrary data stream, and the EVP functions
> take care of carving it up into block-sized chunks and feeding each
> chunk to the cipher function. Finally, the EVP functions take care of

The format of these chunks is entirely protocol depended and thus is not
a good choice for a low level API.  You think that CMS is what everyone
needs, I use OpenPGP more often and Joe Hacker thinks that BAR/9001 is a
better protocol and thus wants an API to fit its outer formatting rules.


Salam-Shalom,

   Werner

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




From n.mavrogiannopoulos at gmail.com  Mon Nov 19 14:43:56 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 19 Nov 2007 15:43:56 +0200
Subject: [gnutls-dev] Lack of documented standard for exporting DSA
	priv_keys in PKCS8 format??
In-Reply-To: <1195467474.15058.11.camel@localhost>
References: <1195467474.15058.11.camel@localhost>
Message-ID: <c331d99a0711190543k93b0c16o41eb4e658858bd79@mail.gmail.com>

On Nov 19, 2007 12:17 PM, David Mar?n Carre?o <davefx at gmail.com> wrote:
> Hi all.
>
> I'm currently developing gnoMint[1], a program for graphically managing
> a CA.
>
> I've just realized that DSA private keys cannot be exported to PKCS8
> format, "since there is no documented standard for other keys" than RSA,
> according to the manual page.
>
> However, in PKCS11 document[2], in page 248 (section 12.6), it is said
> how to wrap and unwrap, among others, DSA private keys, in PKCS#8's
> PrivateKeyInfo ASN.1 type.
>
> I don't know if this can be considered a "documented standard", but I
> think it is.

Are you sure the referenced document defines such thing? It has only 3
sections  and 26 pages.
I remember I also had problems finding this document when I was
developing it. If you can find
references to it I could implement and document it.

regards,
Nikos



From davefx at gmail.com  Mon Nov 19 15:10:59 2007
From: davefx at gmail.com (David =?ISO-8859-1?Q?Mar=EDn_Carre=F1o?=)
Date: Mon, 19 Nov 2007 15:10:59 +0100
Subject: [gnutls-dev] Lack of documented standard for exporting
	DSA	priv_keys in PKCS8 format??
In-Reply-To: <c331d99a0711190543k93b0c16o41eb4e658858bd79@mail.gmail.com>
References: <1195467474.15058.11.camel@localhost>
	<c331d99a0711190543k93b0c16o41eb4e658858bd79@mail.gmail.com>
Message-ID: <1195481459.15058.19.camel@localhost>


El lun, 19-11-2007 a las 15:43 +0200, Nikos Mavrogiannopoulos escribi?:

> Are you sure the referenced document defines such thing? It has only 3
> sections  and 26 pages.
> I remember I also had problems finding this document when I was
> developing it. If you can find
> references to it I could implement and document it.
> 

Sorry, I put the wrong link. It should be:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

I see that OpenSSL follows a previous version of this document. From
OpenSSL's pkcs8 man page:
"The format of PKCS#8 DSA (and other) private keys is not well
documented: it is hidden away in PKCS#11 v2.01, section 11.9. OpenSSL's
default DSA PKCS#8 private key format complies with this standard."

Section 11.9 of version 2.01 corresponds to section 12.6 of version
2.20.

Other references in the web also point to this document. From
http://www.drh-consultancy.demon.co.uk/pkcs12faq.html :

        Can PKCS#12 be used for non RSA private keys, for example DSA
        and DH keys?
        Yes it can. PKCS#12 uses PKCS#8 for storing private keys but
        PKCS#8 itself only gives information about RSA. PKCS#11 however
        extends PKCS#8 and provides a standard for storing DSA and DH
        private keys using PKCS#8. Netscape follows the PKCS#11
        extension to PKCS#8 for DSA private keys. For more information
        see the PKCS#11 specification.
        
Thank you for your support

Best regards,
-- 
David Mar?n Carre?o <davefx at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3204 bytes
Desc: not available
URL: </pipermail/attachments/20071119/936139f0/attachment.bin>

From mrsam at courier-mta.com  Tue Nov 20 00:31:13 2007
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 19 Nov 2007 18:31:13 -0500
Subject: [gnutls-dev] Symmetric cipher API
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
	<200711190838.17890.nmav@gnutls.org>
	<cone.1195474442.570650.12944.500@commodore.email-scan.com>
	<87bq9qqs14.fsf@wheatstone.g10code.de>
Message-ID: <cone.1195515073.350073.17106.500@commodore.email-scan.com>

Werner Koch writes:

> On Mon, 19 Nov 2007 13:14, mrsam at courier-mta.com said:
> 
>> input piece-meal, as an arbitrary data stream, and the EVP functions
>> take care of carving it up into block-sized chunks and feeding each
>> chunk to the cipher function. Finally, the EVP functions take care of
> 
> The format of these chunks is entirely protocol depended and thus is not
> a good choice for a low level API.  You think that CMS is what everyone
> needs, I use OpenPGP more often and Joe Hacker thinks that BAR/9001 is a
> better protocol and thus wants an API to fit its outer formatting rules.

I'm not sure I understand what exactly is so protocol-dependent here. An 
application needs to encrypt 900 bytes using a symmetric cipher with a block 
size of 8 bytes. It looks to me like the only option here is 112, 
continuous, full blocks and one partial block, using PKCS padding. That's 
pretty much a standard, if there is one, and the EVP_CIPHER API that was 
introduced in OpenSSL 0.9.7a greatly simplified the whole process for me, as 
an application developer. It's all documented here: 
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html

Anyway, I wrote and tested the libgcrypt equivalent which emulates enough of 
the above API to allow me to compile existing OpenSSL code that uses the 
API, without any changes. As I said, it's yours for asking; and I would even 
suggest turning it into a native libgcrypt API, with lightweight 
OpenSSL-compatible glue; instead of just putting it into libgnutls-extra 
verbatim, as is.


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

From wk at gnupg.org  Tue Nov 20 09:18:44 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Nov 2007 09:18:44 +0100
Subject: [gnutls-dev] Symmetric cipher API
In-Reply-To: <cone.1195515073.350073.17106.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Mon, 19 Nov 2007 18:31:13 -0500")
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
	<200711190838.17890.nmav@gnutls.org>
	<cone.1195474442.570650.12944.500@commodore.email-scan.com>
	<87bq9qqs14.fsf@wheatstone.g10code.de>
	<cone.1195515073.350073.17106.500@commodore.email-scan.com>
Message-ID: <87zlx9misb.fsf@wheatstone.g10code.de>

On Tue, 20 Nov 2007 00:31, mrsam at courier-mta.com said:

> I'm not sure I understand what exactly is so protocol-dependent
> here. An application needs to encrypt 900 bytes using a symmetric
> cipher with a block size of 8 bytes. It looks to me like the only
> option here is 112, continuous, full blocks and one partial block,
> using PKCS padding. That's pretty much a standard, if there is one,

Most of it is protocol dependent.  What mode does the protocol require,
does it require padding, how is the padding done, is there a higher
level of blocking required, are there special variants of the mode to be
employed and so on.  A lot of parameters and not everyone is using CBC
with the de-facto standard padding as CMS (pkcs#7) encryption does.


Salam-Shalom,

   Werner

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




From nmav at gnutls.org  Wed Nov 21 21:21:55 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 Nov 2007 22:21:55 +0200
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <87abpcdky8.fsf@mocca.josefsson.org>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<200711171633.22231.nmav@gnutls.org>
	<87abpcdky8.fsf@mocca.josefsson.org>
Message-ID: <200711212221.55847.nmav@gnutls.org>

On Sunday 18 November 2007, Simon Josefsson wrote:

> > What I had thought then was to make this parsing routine output the
> > result in a gnutls_priority_st structure and then associate this
> > struction with every session. If found that solution complex then...
>
> How about implementing the simple gnutls_set_priority function now, and
> if it turns out that it is actually a performance bottle-neck for some
> applications, we can add a gnutls_parse_priority and a new
> gnutls_set_preparsed_priority function to handle that.  I think for 90 %
> of the applications, the inefficiency doesn't matter.  Premature
> optimization is the root of all evil etc...

As it turns out using the current api with the strings, it might be more
convenient if the priorities are parsed initially and cached. That is because
on a server you don't want to print a parsing error of the priority string
on the first connection. That has to be done while parsing the configuration
file or command line. If I find some time this week I'll update the 
repository.

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Wed Nov 21 22:58:33 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 21 Nov 2007 23:58:33 +0200
Subject: [gnutls-dev] Lack of documented standard for exporting DSA
	priv_keys in PKCS8 format??
In-Reply-To: <1195481459.15058.19.camel@localhost>
References: <1195467474.15058.11.camel@localhost>
	<c331d99a0711190543k93b0c16o41eb4e658858bd79@mail.gmail.com>
	<1195481459.15058.19.camel@localhost>
Message-ID: <200711212358.33320.n.mavrogiannopoulos@gmail.com>

On Monday 19 November 2007, David Mar?n Carre?o wrote:

> Sorry, I put the wrong link. It should be:
> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf
> I see that OpenSSL follows a previous version of this document. From
> OpenSSL's pkcs8 man page:
> "The format of PKCS#8 DSA (and other) private keys is not well
> documented: it is hidden away in PKCS#11 v2.01, section 11.9. OpenSSL's
> default DSA PKCS#8 private key format complies with this standard."

Thank you. I'll check this document and try to implement it as soon as I have 
some free time, from a quick glimpse it doesn't look that hard.

regards,
Nikos





From mrsam at courier-mta.com  Thu Nov 22 00:22:14 2007
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Wed, 21 Nov 2007 18:22:14 -0500
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
 changes
References: <871wasbyam.fsf@mocca.josefsson.org>
	<200711171633.22231.nmav@gnutls.org>
	<87abpcdky8.fsf@mocca.josefsson.org>
	<200711212221.55847.nmav@gnutls.org>
Message-ID: <cone.1195687334.179281.5944.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> On Sunday 18 November 2007, Simon Josefsson wrote:
> 
>> > What I had thought then was to make this parsing routine output the
>> > result in a gnutls_priority_st structure and then associate this
>> > struction with every session. If found that solution complex then...
>>
>> How about implementing the simple gnutls_set_priority function now, and
>> if it turns out that it is actually a performance bottle-neck for some
>> applications, we can add a gnutls_parse_priority and a new
>> gnutls_set_preparsed_priority function to handle that.  I think for 90 %
>> of the applications, the inefficiency doesn't matter.  Premature
>> optimization is the root of all evil etc...
> 
> As it turns out using the current api with the strings, it might be more
> convenient if the priorities are parsed initially and cached. That is because
> on a server you don't want to print a parsing error of the priority string
> on the first connection. That has to be done while parsing the configuration
> file or command line. If I find some time this week I'll update the 
> repository.

My recollection of OpenSSL's behavior is that it simply ignores unrecognized 
protocol names. The advantages to that approach is that certain ciphers and 
algorithms can be selectively enabled or disabled when building OpenSSL, for 
various reasons, and the applications can simply use a generic, 
one-size-fits-all configuration settings, without having to deal with errors 
due to the base distribution's decision to disable certain ciphers.

I know that at least Fedora's build of GnuTLS does not enable all ciphers. 
At least give applications an option to ignore unknown ciphers, or flag them 
as errors.


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

From nmav at gnutls.org  Thu Nov 22 22:05:41 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 22 Nov 2007 23:05:41 +0200
Subject: [gnutls-dev] Work in progress: GnuTLS 2.2 release notes on API
	changes
In-Reply-To: <cone.1195687334.179281.5944.500@commodore.email-scan.com>
References: <871wasbyam.fsf@mocca.josefsson.org>
	<200711212221.55847.nmav@gnutls.org>
	<cone.1195687334.179281.5944.500@commodore.email-scan.com>
Message-ID: <200711222305.41615.nmav@gnutls.org>

On Thursday 22 November 2007, Sam Varshavchik wrote:

> > As it turns out using the current api with the strings, it might be more
> > convenient if the priorities are parsed initially and cached. That is
> > because on a server you don't want to print a parsing error of the
> > priority string on the first connection. That has to be done while
> > parsing the configuration file or command line. If I find some time this
> > week I'll update the repository.
>
> My recollection of OpenSSL's behavior is that it simply ignores
> unrecognized protocol names. The advantages to that approach is that
> certain ciphers and algorithms can be selectively enabled or disabled when
> building OpenSSL, for various reasons, and the applications can simply use
> a generic,

This is not that good. I might set +AES-128 but negotiate ARCFOUR because I 
had a typo and didn't specify AES-128-CBC.

> one-size-fits-all configuration settings, without having to deal with
> errors due to the base distribution's decision to disable certain ciphers.

Then they should be responsible to warn the user and remove such references.
Removing ciphers and silently letting the user believe he's using them does 
not sound good to me.

> I know that at least Fedora's build of GnuTLS does not enable all ciphers.
> At least give applications an option to ignore unknown ciphers, or flag
> them as errors.

I'm quite afraid of such a flag, but I'll think about it.

regards,
Nikos



From nmav at gnutls.org  Sun Nov 25 00:11:04 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Nov 2007 01:11:04 +0200
Subject: [gnutls-dev]
	=?utf-8?q?Lack_of_documented_standard_for_exporting_?=
	=?utf-8?q?DSA_priv=5Fkeys_in_PKCS8=09format=3F=3F?=
In-Reply-To: <1195467474.15058.11.camel@localhost>
References: <1195467474.15058.11.camel@localhost>
Message-ID: <200711250111.04869.nmav@gnutls.org>

On Monday 19 November 2007, David Mar?n Carre?o wrote:
> Hi all.
>
> I'm currently developing gnoMint[1], a program for graphically managing
> a CA.
>
> I've just realized that DSA private keys cannot be exported to PKCS8
> format, "since there is no documented standard for other keys" than RSA,
> according to the manual page.

I have added some support for PKCS #8 DSA keys in the git repository.
If you would like to assist in testing please free to do so.


regards,
Nikos





From simon at josefsson.org  Sun Nov 25 16:14:48 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 25 Nov 2007 16:14:48 +0100
Subject: [gnutls-dev] Symmetric cipher API
In-Reply-To: <cone.1195420345.490721.24664.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Sun, 18 Nov 2007 16:12:25 -0500")
References: <cone.1195420345.490721.24664.500@commodore.email-scan.com>
Message-ID: <87fxyumk5z.fsf@mocca.josefsson.org>

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

> Recently I converted some code that uses OpenSSL's EVP_CIPHER
> symmetric cipher API. I wrote a wrapper that mapped the following
> functions to their gcrypt equivalents: EVP_CIPHER_CTX_init(),
> EVP_CIPHER_CTX_cleanup(), EVP_(Encrypt|Decrypt)Init_ex(),
> EVP_(Encrypt|Decrypt)Update(), and EVP_(Encrypt|Decrypt)Final_ex().
>
> If you are interested, I'll be happy to contribute this code.

That sounds like a useful addition for gnutls-openssl to me, please post
the patch and we can review it.  If you haven't signed a copyright
assignment with the FSF, you'll need to do that before we can accept the
patch though.  Let me know privately and I'll send the form.

> I also thought that it's better to make this a native libgcrypt
> API. This should be only a matter of renaming the function names and
> arguments to follow libgcrypt's naming conventions, and all the EVP
> function become now just some lightweight wrappers (or probably even
> macros).

That would be something for the libgcrypt maintainers to consider.  In
any case, patches to improve the OpenSSL compatibility layer in GnuTLS
are always welcome.

/Simon



From simon at josefsson.org  Wed Nov 28 12:22:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Nov 2007 12:22:07 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <20071118145546.GA4675@downhill.g.la> (Andreas Metzler's message
	of "Sun, 18 Nov 2007 15:55:46 +0100")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
Message-ID: <87prxumx7k.fsf@mocca.josefsson.org>

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

> On 2007-11-17 Simon Josefsson <simon at josefsson.org> wrote:
>> Hi!  Since I'm going away on vacation for one week, and the December 1th
>> date is approaching, I'm declaring that 2.1.6 should be considered a
>> release candidate for the version 2.2 release.
> [...]
>
> Hello,
>
> FWIW I have uploaded it to Debian experimental.
>
> http://qa.debian.org/developer.php?login=pkg-gnutls-maint at lists.alioth.debian.org
>
> It will probably not get a lot of testing there, but we'll see at
> least whether autobuilding works.

The buildd link doesn't seem too encouraging... or am I missing
something?

Anyway, we'll need a 2.1.7 that will bump the so revision again, alas,
and after that we are hopefully set for 2.2.  Also hopefully, libgcrypt
will be released and declared stable.

/Simon



From simon at josefsson.org  Wed Nov 28 12:27:52 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Nov 2007 12:27:52 +0100
Subject: [gnutls-dev] [PATCH] Load DH Params from File
In-Reply-To: <200710121717.00092.gtefjknerfd@stobor.net> (Allwyn Fernandes's
	message of "Fri, 12 Oct 2007 17:16:59 +1000")
References: <200710121717.00092.gtefjknerfd@stobor.net>
Message-ID: <87ir3mmwxz.fsf@mocca.josefsson.org>

Mr Allwyn Fernandes <gtefjknerfd at stobor.net> writes:

> Hi,
>
> (Apologies if anyone gets this multiple times: I've tried sending it several 
> times, and keep getting bounce messages... I don't see it in any of the 
> archives so I _suspect_ it hasn't gotten through to anyone, but I'm not 
> sure.)

Hi!  Sorry about that, I think the gnutls-dev at gnupg.org list is
subscribers-only.  We will move it to gnu.org soon to solve that and
other problems but we haven't had time yet.  Sorry for slow response as
well.

> I recently added GnuTLS support to an app, and noticed a slight inconsistancy 
> in the api; one can load certificates, keys and CRLs directly from a file, 
> but there is no corresponding function which takes a filename and loads the 
> DH params from the file. I'm using Debian Testing, which has gnutls13-1.7.19, 
> but I noted that the current online documentation doesn't list a new method 
> to do this either.

Right.

> I have created a trivial patch which implements an api 
> function "gnutls_dh_params_import_pkcs3_file" from a combination 
> of "gnutls_dh_params_import_pkcs3" and "gnutls_certificate_set_x509_crl_file"
>
> I have generated the patch against Debian's gnutls13-1.7.19 source, but 
> appears to apply reasonably to the 2.0.1 source... Otherwise, for easy 
> cut-n-paste, the new method is listed below, along with the corresponding 
> header entry.
>
> If there are any comments or questions, please feel free to let me know.

Your patch looks fine to me.  To be able to install it, we will need a
copyright assignment.  I'll send this off-list to you.

Thanks,
Simon



From ametzler at downhill.at.eu.org  Wed Nov 28 19:09:40 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 28 Nov 2007 19:09:40 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <87prxumx7k.fsf@mocca.josefsson.org>
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
	<87prxumx7k.fsf@mocca.josefsson.org>
Message-ID: <20071128180940.GB4533@downhill.g.la>

On 2007-11-28 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > It will probably not get a lot of testing there, but we'll see at
> > least whether autobuilding works.

> The buildd link doesn't seem too encouraging... or am I missing
> something?
[...]

It is not a GnuTLS error but a limitation of how autobuilding
experimental (does not) work.

libgcrypt11 (1.2.4) is part of the base system. The new GnuTLS
requires 1.3.x, but the autobuilders will not upgrade a pre-existing
package.
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 gtefjknerfd at stobor.net  Thu Nov 29 04:09:57 2007
From: gtefjknerfd at stobor.net (Mr Allwyn Fernandes)
Date: Thu, 29 Nov 2007 14:09:57 +1100
Subject: [gnutls-dev] [PATCH] Load DH Params from File
In-Reply-To: <87ir3mmwxz.fsf@mocca.josefsson.org>
References: <200710121717.00092.gtefjknerfd@stobor.net>
	<87ir3mmwxz.fsf@mocca.josefsson.org>
Message-ID: <200711291409.58300.gtefjknerfd@stobor.net>

Hi Simon,

On Wed, 28 Nov 2007 10:27:52 pm Simon Josefsson wrote:
> Hi!  Sorry about that, I think the gnutls-dev at gnupg.org list is
> subscribers-only.  We will move it to gnu.org soon to solve that and
> other problems but we haven't had time yet.  Sorry for slow response as
> well.

No problems... My message got through in the end, so I'm not too 
concerned. :-)

My main worry is that the bugs@ address is advertised as the main way to 
report bugs, but it is something of roadblock... Even after subscribing to 
one mailing list (gnutls-dev), users get bounce messages from other mailing 
lists which they are asked to subscribe to... Maybe having that address go to 
some other mbox, so at least people can report bugs there, and have them 
discussed on the dev list later?

> > I have created a trivial patch which implements an api
> > function "gnutls_dh_params_import_pkcs3_file" from a combination
> > of "gnutls_dh_params_import_pkcs3" and
> > "gnutls_certificate_set_x509_crl_file"
[...snip...]  
> Your patch looks fine to me.  

Cool, I'm glad to hear that. What do you think of Nikos's concerns?

On Fri, 12 Oct 2007 06:28:37 pm Nikos Mavrogiannopoulos wrote:
> Concerning your patch, first
> thank you for working on it, but it seems it is not consistent with our
> current interface. Although there are functions that load from file, the
> functions that import data to structures (like the dhparams or the x509
> certificates) do not have the ability to load from files. If we add this
> patch we will also need to modify those interfaces to act similarly. This
> involves a significant number of functions, being added and thus I think it
> requires more thought.

From my perspective, at the very least dhparams needs some sort of load 
function, since it is required for every server application of gnutls. (It's 
even required in the minimal examples...) If there are other structures which 
can save data in DER/PEM/PKCS encodings, and they already have "load from 
memory" functions, then implementing a "load from file" function should be a 
trivial pair of calls, read_binary_file() followed by 
gnutls_STRUCTURE_import(), as was done in this patch for dh_params. The real 
requirement is to enumerate any such structures, which I haven't yet got 
around to...

> To be able to install it, we will need a 
> copyright assignment.  I'll send this off-list to you.

I'll follow this up. :)

Cheers,

Allwyn.



From simon at josefsson.org  Thu Nov 29 12:25:38 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Nov 2007 12:25:38 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <20071128180940.GB4533@downhill.g.la> (Andreas Metzler's message
	of "Wed, 28 Nov 2007 19:09:40 +0100")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
	<87prxumx7k.fsf@mocca.josefsson.org>
	<20071128180940.GB4533@downhill.g.la>
Message-ID: <87fxypthsd.fsf@mocca.josefsson.org>

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

> On 2007-11-28 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > It will probably not get a lot of testing there, but we'll see at
>> > least whether autobuilding works.
>
>> The buildd link doesn't seem too encouraging... or am I missing
>> something?
> [...]
>
> It is not a GnuTLS error but a limitation of how autobuilding
> experimental (does not) work.
>
> libgcrypt11 (1.2.4) is part of the base system. The new GnuTLS
> requires 1.3.x, but the autobuilders will not upgrade a pre-existing
> package.

Ah, I see.  If we wait for libgcrypt to become stable (which was only a
few weeks away if I understand correctly), will it be uploaded into
debian relatively quickly, and installed on the builds, to allow the
gnutls build to come through?

It seems clear that we won't be able to release on 1 Dec, while there
are no major outstanding bugs, the unreleased trunk contains new stuff
that needs to be tested.  So we could aim for Dec 15 or something
instead, which might give us time to wait for the buildd's to test it.

/Simon



From simon at josefsson.org  Thu Nov 29 15:24:18 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Nov 2007 15:24:18 +0100
Subject: [gnutls-dev] GnuTLS 2.1.7
Message-ID: <87abox9lkd.fsf@mocca.josefsson.org>

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

Consider this a release candidate for version 2.2.  We plan to release
this within two weeks or so.

We are considering to use the GPLv3 instead of GPLv2 for everything
except the core library, and I'd like to invite comments about this.

We know that the LZO library is GPLv2 only, even though earlier versions
are GPLv2 or later, and we suggest to disable LZO functionality if this
is a problem.  LZO compression is not a standard feature in TLS, and we
may decide to disable it by default.  Opinions on that are appreciated
as well.  I'll try to understand what the license status is on LZO, I
know some people was going to contact the author of it some time ago..

News in this release:

* Version 2.1.7 (released 2007-11-29)

** PKCS #8 parser can now encode/decode DSA keys.

** We now ignore received packets with unknown content types
to follow the TLS spec.

** Updated gnutls_set_default_priority2() now renamed to
gnutls_priority_set() and gnutls_priority_set_direct() which
accept a string to indicate preferences of ciphersuite parameters.

** gnutls-cli and gnutls-serv now have a --priority option to set
the priority string.

** The gnutls_*_convert_priority() functions were deprecated by
the gnutls_priority_set() and gnutls_priority_set_direct().

** Internal copy of OpenCDK upgraded to version 0.6.6.

** API and ABI modifications:
gnutls_priority_init: ADD.
gnutls_priority_deinit: ADD.
gnutls_priority_set: ADD.
gnutls_priority_set_direct: ADD.
gnutls_set_default_priority2: RENAMED to gnutls_priority_set_direct()
gnutls_mac_convert_priority: REMOVED
gnutls_compression_convert_priority: REMOVED
gnutls_protocol_convert_priority: REMOVED
gnutls_kx_convert_priority: REMOVED
gnutls_cipher_convert_priority: REMOVED
gnutls_certificate_type_convert_priority: REMOVED
gnutls_set_default_priority: UNDEPRECATED
gnutls_set_default_priority_export: UNDEPRECATED

** Undocumented API and ABI modifications earlier in the 2.1.x series:
GNUTLS_CIPHER_UNKNOWN: ADD.
GNUTLS_CIPHER_CAMELLIA_128_CBC: ADD.
GNUTLS_CIPHER_CAMELLIA_256_CBC: ADD.
GNUTLS_KX_UNKNOWN: ADD.
GNUTLS_COMP_UNKNOWN: ADD.
GNUTLS_CRT_UNKNOWN: ADD.
gnutls_mac_get_id: ADD.
gnutls_compression_get_id: ADD.
gnutls_cipher_get_id: ADD.
gnutls_kx_get_id: ADD.
gnutls_protocol_get_id: ADD.
gnutls_certificate_type_get_id: ADD.
gnutls_handshake_post_client_hello_func: ADD.
gnutls_certificate_send_x509_rdn_sequence: ADD prototype to gnutls.h.in.

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

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

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.7.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.1.7.tar.bz2

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

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

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

From simon at josefsson.org  Thu Nov 29 15:26:43 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Nov 2007 15:26:43 +0100
Subject: [gnutls-dev] Updated release notes about API/ABI break
Message-ID: <8763zl9lgc.fsf@mocca.josefsson.org>

Updated to align with 2.1.7.  Hopefully this will be the final text.
Comments solicited.

/Simon

Backwards incompatible API/ABI changes in GnuTLS 2.2
====================================================

To adapt to changes in the TLS extension specifications for OpenPGP
and SRP, the GnuTLS API had to be modified.  This means breaking the
API and ABI backwards compatibility.  That is something we try to
avoid unless it is necessary.  We decided to also remove the already
deprecated stub functions for X.509 to XML conversion and TLS
authorization (see below) when we had the opportunity.

Generally, most applications does not need to be modified.  Just
re-compile them against the latest GnuTLS release, and it should work
fine.

Applications that use the OpenPGP or SRP features needs to be
modified.  Below is a list of the modified APIs and discussion of what
the minimal things you need to modify in your application to make it
work with GnuTLS 2.2.

Note that GnuTLS 2.2 also introduces new APIs -- such as
gnutls_set_priority() that is superior to
gnutls_set_default_priority() -- that you may want to start using.
However, using those new APIs is not required to use GnuTLS 2.2 since
the old functions continue are still supported.  This text only
discuss what you minimally have to modify.

XML related changes
-------------------

The function `gnutls_x509_crt_to_xml' has been removed.  It has been
deprecated and only returned an error code since GnuTLS version
1.2.11.  Nobody has complained, so users doesn't seem to miss the
functionality.  We don't know of any other library to convert X.509
certificates into XML format, but we decided (long ago) that GnuTLS
isn't the right place for this kind of functionality.  If you want
help to find some other library to use here, please explain and
discuss your use case on help-gnutls at gnu.org.

TLS Authorization related changes
---------------------------------

Everything related to TLS authorizations have been removed, they were
only stub functions that returned an error code:

 GNUTLS_SUPPLEMENTAL_AUTHZ_DATA
 gnutls_authz_data_format_type_t
 gnutls_authz_recv_callback_func
 gnutls_authz_send_callback_func
 gnutls_authz_enable
 gnutls_authz_send_x509_attr_cert
 gnutls_authz_send_saml_assertion
 gnutls_authz_send_x509_attr_cert_url
 gnutls_authz_send_saml_assertion_url

SRP related changes
-------------------

The callback gnutls_srp_client_credentials_function has a new
prototype, and its semantic has changed.  You need to rewrite the
callback, see the updated function documentation and SRP example code
(doc/examples/ex-client-srp.c and doc/examples/ex-serv-srp.c) for more
information.

The alert codes GNUTLS_A_MISSING_SRP_USERNAME and
GNUTLS_A_UNKNOWN_SRP_USERNAME are no longer used by the SRP
specification, instead the GNUTLS_A_UNKNOWN_PSK_IDENTITY alert is
used.  There are #define's to map the old names to the new.  You may
run into problems if you have a switch-case with cases for both SRP
alerts, since they are now mapped to the same value.  The solution is
to drop the SRP alerts from such switch cases, as they are now
deprecated in favor of GNUTLS_A_UNKNOWN_PSK_IDENTITY.

OpenPGP related changes
-----------------------

The function `gnutls_certificate_set_openpgp_keyserver' have been
removed.  There is no replacement functionality inside GnuTLS.  If you
need keyserver functionality, consider using the GnuPG tools.

All functions, types, and error codes related to OpenPGP trustdb
format have been removed.  The trustdb format is a non-standard
GnuPG-specific format, and we recommend you to use key rings instead.
The following have been removed:

 gnutls_certificate_set_openpgp_trustdb
 gnutls_openpgp_trustdb_init
 gnutls_openpgp_trustdb_deinit
 gnutls_openpgp_trustdb_import
 gnutls_openpgp_key_verify_trustdb
 gnutls_openpgp_trustdb_t
 GNUTLS_E_OPENPGP_TRUSTDB_VERSION_UNSUPPORTED

The following functions has an added parameter of the (new) type
`gnutls_openpgp_crt_fmt_t'.  The type specify the format of the data
(binary or base64).  The functions are:
 gnutls_certificate_set_openpgp_key_file
 gnutls_certificate_set_openpgp_key_mem
 gnutls_certificate_set_openpgp_keyring_mem
 gnutls_certificate_set_openpgp_keyring_file

To improve terminology and align with the X.509 interface, some
functions have been renamed.  Compatibility mappings exists.  The old
and new names of the affected functions and types are:

        Old name                                New name
 gnutls_openpgp_key_t                    gnutls_openpgp_crt_t
 gnutls_openpgp_key_fmt_t                gnutls_openpgp_crt_fmt_t
 gnutls_openpgp_key_status_t             gnutls_openpgp_crt_status_t
 GNUTLS_OPENPGP_KEY                      GNUTLS_OPENPGP_CERT
 GNUTLS_OPENPGP_KEY_FINGERPRINT          GNUTLS_OPENPGP_CERT_FINGERPRINT
 gnutls_openpgp_key_init                 gnutls_openpgp_crt_init
 gnutls_openpgp_key_deinit               gnutls_openpgp_crt_deinit
 gnutls_openpgp_key_import               gnutls_openpgp_crt_import
 gnutls_openpgp_key_export               gnutls_openpgp_crt_export
 gnutls_openpgp_key_get_key_usage        gnutls_openpgp_crt_get_key_usage
 gnutls_openpgp_key_get_fingerprint      gnutls_openpgp_crt_get_fingerprint
 gnutls_openpgp_key_get_pk_algorithm     gnutls_openpgp_crt_get_pk_algorithm
 gnutls_openpgp_key_get_name             gnutls_openpgp_crt_get_name
 gnutls_openpgp_key_get_version          gnutls_openpgp_crt_get_version
 gnutls_openpgp_key_get_creation_time    gnutls_openpgp_crt_get_creation_time
 gnutls_openpgp_key_get_expiration_time  gnutls_openpgp_crt_get_expiration_time
 gnutls_openpgp_key_get_id               gnutls_openpgp_crt_get_id
 gnutls_openpgp_key_check_hostname       gnutls_openpgp_crt_check_hostname
 gnutls_openpgp_send_key                 gnutls_openpgp_send_cert



From ametzler at downhill.at.eu.org  Thu Nov 29 18:59:25 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 29 Nov 2007 18:59:25 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <87fxypthsd.fsf@mocca.josefsson.org>
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
	<87prxumx7k.fsf@mocca.josefsson.org>
	<20071128180940.GB4533@downhill.g.la>
	<87fxypthsd.fsf@mocca.josefsson.org>
Message-ID: <20071129175925.GA5086@downhill.g.la>

On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
[...]
> If we wait for libgcrypt to become stable (which was only a
> few weeks away if I understand correctly), will it be uploaded into
> debian relatively quickly, and installed on the builds, to allow the
> gnutls build to come through?
[...]

Hello,

I will do my best to upload the new stable libgcrypt as quick as
possible. It might still take a couple of days to so though.

cu andreas



From simon at josefsson.org  Fri Nov 30 14:59:14 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 Nov 2007 14:59:14 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <20071129175925.GA5086@downhill.g.la> (Andreas Metzler's message
	of "Thu, 29 Nov 2007 18:59:25 +0100")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
	<87prxumx7k.fsf@mocca.josefsson.org>
	<20071128180940.GB4533@downhill.g.la>
	<87fxypthsd.fsf@mocca.josefsson.org>
	<20071129175925.GA5086@downhill.g.la>
Message-ID: <874pf3j0lp.fsf@mocca.josefsson.org>

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

> On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
> [...]
>> If we wait for libgcrypt to become stable (which was only a
>> few weeks away if I understand correctly), will it be uploaded into
>> debian relatively quickly, and installed on the builds, to allow the
>> gnutls build to come through?
> [...]
>
> Hello,
>
> I will do my best to upload the new stable libgcrypt as quick as
> possible. It might still take a couple of days to so though.

Great, thanks.

/Simon



From wk at gnupg.org  Fri Nov 30 18:44:33 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 30 Nov 2007 18:44:33 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <87fxypthsd.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 29 Nov 2007 12:25:38 +0100")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<20071118145546.GA4675@downhill.g.la>
	<87prxumx7k.fsf@mocca.josefsson.org>
	<20071128180940.GB4533@downhill.g.la>
	<87fxypthsd.fsf@mocca.josefsson.org>
Message-ID: <8763zjwrum.fsf@wheatstone.g10code.de>

On Thu, 29 Nov 2007 12:25, simon at josefsson.org said:

> Ah, I see.  If we wait for libgcrypt to become stable (which was only a
> few weeks away if I understand correctly), will it be uploaded into

Well, you force me to release it sooner than expected.  I will do a new
devel release the next days and ask people to test it on several
platforms - in particular on VIA to see that I did not broke anything.

A final release can then be done in ~10 days which would fit your
release plan I hope.



Salam-Shalom,

   Werner

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




From nmav at gnutls.org  Fri Nov 30 20:57:26 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Nov 2007 21:57:26 +0200
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <8763zjwrum.fsf@wheatstone.g10code.de>
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<87fxypthsd.fsf@mocca.josefsson.org>
	<8763zjwrum.fsf@wheatstone.g10code.de>
Message-ID: <200711302157.27116.nmav@gnutls.org>

On Friday 30 November 2007, Werner Koch wrote:
> On Thu, 29 Nov 2007 12:25, simon at josefsson.org said:
> > Ah, I see.  If we wait for libgcrypt to become stable (which was only a
> > few weeks away if I understand correctly), will it be uploaded into
>
> Well, you force me to release it sooner than expected.  I will do a new
> devel release the next days and ask people to test it on several
> platforms - in particular on VIA to see that I did not broke anything.
>
> A final release can then be done in ~10 days which would fit your
> release plan I hope.

Maybe we can depend on libgcrypt 1.2.x temporarily. The functionality that we 
lose is the DSA2 signing, which is not so critical to be included now. 

(I also like the Via stuff and I'll include it at the test?.gnutls.org 
servers).

regards,
Nikos





From nmav at gnutls.org  Fri Nov 30 21:44:44 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 30 Nov 2007 22:44:44 +0200
Subject: [gnutls-dev] mod_gnutls 0.4.0
Message-ID: <200711302244.44814.nmav@gnutls.org>

Hello,
 I've released today mod_gnutls 0.4.0. This release compared to the 0.3.x 
releases adds ciphersuite selection using a single GnuTLSPriorities 
directive.

The new directive is described at:
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/#GnuTLSPriorities

Some new (virtual) test servers for SNI and SRP support are listed in:
http://www.outoforder.cc/projects/apache/mod_gnutls/sni/

This version is available for testing at the main mod_gnutls site (thanks to 
Paul Querna and Edward Rudd). Suggestions and bug reports are welcome.

My main priorities now are to take care of the reports at
http://issues.outoforder.cc/view_all_bug_page.php
and add OpenPGP certificate support (RFC 5081) to mod_gnutls.


regards,
Nikos