From simon at josefsson.org  Sat Dec  1 10:54:40 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 01 Dec 2007 10:54:40 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <200711302157.27116.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Fri, 30 Nov 2007 21:57:26 +0200")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<87fxypthsd.fsf@mocca.josefsson.org>
	<8763zjwrum.fsf@wheatstone.g10code.de>
	<200711302157.27116.nmav@gnutls.org>
Message-ID: <87lk8e4u5b.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

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

Yes, I think this is better, if the release schedule libgcrypt is a
problem.  I see you committed this, thanks.  GnuTLS 2.2 will only need
libgcrypt 1.2.x then.

/Simon



From ametzler at downhill.at.eu.org  Sat Dec  1 20:16:47 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 1 Dec 2007 20:16:47 +0100
Subject: [gnutls-dev] Please update lib-link.m4
Message-ID: <20071201191647.GH7656@downhill.g.la>

Hello,

the old verion of lib-link.m4 (serial 9) in gnutls 2.1.7 results in
adding a unnecessary -L/usr/lib to the link line for every single
found library. (e.g. opencdk or zlib):

(cd /tmp/GNUTLS/gnutls25-2.1.6/libextra; /bin/bash ../libtool  --tag=CC --mode=relink cc -std=gnu99 -g  -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -L/usr/lib -lopencdk -L/usr/lib -lgcrypt -L/usr/lib -lgpg-error -L/usr/lib -lnsl -L/usr/lib -lz -version-info 25:1:0 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /usr/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la -inst-prefix-dir /tmp/GNUTLS/gnutls25-2.1.6/debian/tmp/)


The additional -L/usr/lib causes libtool to choose the wrong -lgnutls,
prefereing the one in /usr/lib (if it exists) over the newly generated
one in DESTDIR/usr/lib.

<http://news.gmane.org/find-root.php?message_id=%3cfpc325%2dbc5.ln1%40argenau.downhill.at.eu.org%3e>

Upgrading lib-link.m4 from serial 9 to serial 13 gets rid of almost all
instances of -L/usr/lib:

(cd /tmp/GNUTLS/gnutls26-2.1.7/libextra; /bin/bash ../libtool  --tag=CC --mode=relink cc -std=gnu99 -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -lopencdk -version-info 26:0:0 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /usr/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la -inst-prefix-dir /tmp/GNUTLS/gnutls26-2.1.7/debian/tmp/)

Please upgrade lib-link.m4

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



From wk at gnupg.org  Mon Dec  3 11:27:18 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Dec 2007 11:27:18 +0100
Subject: [gnutls-dev] Consider 2.1.6 a release candidate for 2.2!
In-Reply-To: <87lk8e4u5b.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Sat, 01 Dec 2007 10:54:40 +0100")
References: <87k5ohdu5q.fsf@mocca.josefsson.org>
	<87fxypthsd.fsf@mocca.josefsson.org>
	<8763zjwrum.fsf@wheatstone.g10code.de>
	<200711302157.27116.nmav@gnutls.org>
	<87lk8e4u5b.fsf@mocca.josefsson.org>
Message-ID: <874pf0ul89.fsf@wheatstone.g10code.de>

On Sat,  1 Dec 2007 10:54, simon at josefsson.org said:

> Yes, I think this is better, if the release schedule libgcrypt is a
> problem.  I see you committed this, thanks.  GnuTLS 2.2 will only need

I just release 1.3.2 and if no major problems are found I can do 1.4.0
on next Monday.


Shalom-Salam,

   Werner

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




From simon at josefsson.org  Mon Dec  3 11:43:53 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 03 Dec 2007 11:43:53 +0100
Subject: [gnutls-dev] Please update lib-link.m4
In-Reply-To: <20071201191647.GH7656@downhill.g.la> (Andreas Metzler's message
	of "Sat, 1 Dec 2007 20:16:47 +0100")
References: <20071201191647.GH7656@downhill.g.la>
Message-ID: <874pf0njme.fsf@mocca.josefsson.org>

Hi!  Interesting.  We import lib-link.m4 from gnulib, so we should have
the latest version.  However, it seems that lib-link.m4 is imported by
gettext as well, and for some reason that version is included by 'make
dist'.  The ordering of -I's in ACLOCAL_AMFLAGS doesn't seem to matter.
I've installed a cludge to overwrite the gettext files with the gnulib
files, but I'll bring this up on the gnulib list as well, to possibly
find out what the recommended solution is.

Installing gettext 0.17 under /usr/local/ doesn't seem to help either,
it still uses the M4 files from /usr.  And for some reason, the debian
package of gettext 0.17 haven't been built for i386, so I can't update
the coy in /usr.  I'll file a bug about that...

I think we'll need another pre-release to confirm that this is solved.

/Simon

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

> Hello,
>
> the old verion of lib-link.m4 (serial 9) in gnutls 2.1.7 results in
> adding a unnecessary -L/usr/lib to the link line for every single
> found library. (e.g. opencdk or zlib):
>
> (cd /tmp/GNUTLS/gnutls25-2.1.6/libextra; /bin/bash ../libtool  --tag=CC --mode=relink cc -std=gnu99 -g  -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -L/usr/lib -lopencdk -L/usr/lib -lgcrypt -L/usr/lib -lgpg-error -L/usr/lib -lnsl -L/usr/lib -lz -version-info 25:1:0 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /usr/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la -inst-prefix-dir /tmp/GNUTLS/gnutls25-2.1.6/debian/tmp/)
>
>
> The additional -L/usr/lib causes libtool to choose the wrong -lgnutls,
> prefereing the one in /usr/lib (if it exists) over the newly generated
> one in DESTDIR/usr/lib.
>
> <http://news.gmane.org/find-root.php?message_id=%3cfpc325%2dbc5.ln1%40argenau.downhill.at.eu.org%3e>
>
> Upgrading lib-link.m4 from serial 9 to serial 13 gets rid of almost all
> instances of -L/usr/lib:
>
> (cd /tmp/GNUTLS/gnutls26-2.1.7/libextra; /bin/bash ../libtool  --tag=CC --mode=relink cc -std=gnu99 -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -lopencdk -version-info 26:0:0 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /usr/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la -inst-prefix-dir /tmp/GNUTLS/gnutls26-2.1.7/debian/tmp/)
>
> Please upgrade lib-link.m4
>
> thanks, cu andreas 
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'



From alon.barlev at gmail.com  Tue Dec  4 12:52:30 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 4 Dec 2007 13:52:30 +0200
Subject: [gnutls-dev] gnome-keyring PKCS#11 provider implemented
In-Reply-To: <20071203204640.22A2B94C8A9@mx.npubs.com>
References: <20071203204640.22A2B94C8A9@mx.npubs.com>
Message-ID: <9e0cf0bf0712040352k5f63d1a3h8cf70e6c8555889e@mail.gmail.com>

On 12/3/07, Stef Walter <stef-list at memberwebs.com> wrote:
> My email to gnutls-dev didn't seem to make it there, but I figured you
> guys would be interested in this:
>
>
> It took longer than I initially thought, but gnome-keyring now has a
> working  PKCS#11 provider. It supports with RSA and DSA keys,
> certificates etc. and integrates them with the user's login keyring.
>
> Some details:
> http://live.gnome.org/GnomeKeyring/CertificatesKeys
> http://live.gnome.org/GnomeKeyring/ApplicationSetup
> http://live.gnome.org/GnomeKeyring
>
> Implementation notes:
> http://live.gnome.org/GnomeKeyring/Cryptoki
>
> The gnome-keyring PKCS#11 provider is probably a bit young and naive,
> and I'd like to make sure that it works with GnuTLS.
>
> In fact I'd be overjoyed if someone with more crypto knowledge than me
> took a look and made sure it's doing things correctly.
>
> The code is in the SVN trunk of gnome-keyring (slated for GNOME 2.22):
> http://svn.gnome.org/svn/gnome-keyring/trunk/
>
> Cheers,
> Stef Walter
>
>

These are great news!

You can use the test program of gnutls-pkcs11 to test if it works with GnuTLS:
http://alon.barlev.googlepages.com/gnutls-pkcs11

This requires pkcs11-helper dependency from:
http://www.opensc-project.org/pkcs11-helper
Be sure to configure this with --enable-crypto-engine-gnutls

You can run the test program:
src/gnutls-pkcs11-cli --add-provider=@@PROVIDER@@ --cmd=ids
src/gnutls-pkcs11-cli --add-provider=/usr/lib/pkcs11/libasepkcs.so
--cmd=connect --pkcs11-id='@@PKCS#11 ID@@' --host=localhost --port=443

You can test this with some of my other solutions, you can use it with
OpenSSH, OpenVPN, eCryptfs, gnupg-pkcs11-scd, these are compete
applications, so it would be easier.

References:
http://alon.barlev.googlepages.com/open-source

I currently support only RSA based keys. I've never seen (touched) a
token that supports DSA... :)
But I will be happy to extend this to DSA as well.

I also appreciate if you can send me the output of:
pkcs11-dump info @@PROVIDER@@
pkcs11-dump slotlist @@PROVIDER@@
pkcs11-dump dump @@PROVIDER@@ @@SLOT@@ @@PIN@@

pkcs11-dump available from:
http://alon.barlev.googlepages.com/pkcs11-utilities

Best Regards,
Alon Bar-Lev.



From simon at josefsson.org  Mon Dec 10 00:28:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Dec 2007 00:28:37 +0100
Subject: [gnutls-dev] GnuTLS presentation at FSCONS
Message-ID: <877ijnjvmi.fsf@mocca.josefsson.org>

I gave a presentation about GnuTLS at FSCONS on December 8th, and the
presentation is available online:

http://josefsson.org/fscons/fscons-gnutls.pdf

For info about FSCONS (although over for now), see:

http://fscons.org/

The organizers will put videos of the presentation online eventually,
and I'll follow up with a link to it when it is available.

/Simon



From simon at josefsson.org  Mon Dec 10 12:38:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Dec 2007 12:38:20 +0100
Subject: [gnutls-dev] GnuTLS 2.1.8
Message-ID: <87odcyrd8z.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.  I plan to release
this on December 13th if there are no serious reports.

There were no major feedback on the GPLv3 situation, so are now using
GPLv3 for everything that used to use GPLv2.  If the LZO library is
giving you license problems (2.01 is available under GPLv2 or later, so
it works fine, but 2.02 is GPLv2 only and can thus not be linked with
GPLv3 gnutls-extra), our official recommendation is to disable lzo
compression support in GnuTLS.  It is not an official TLS compression
algorithm, so the breakage seems minimal.

News in this release:

* Version 2.1.8 (released 2007-12-10)

** The GPL version has been changed from version 2 to version 3.
This affects the self-tests, command-line tools, the libgnutls-extra
library, the relevant guile parts, and the build environment.

** Added gnutls_x509_crt_get_subject_alt_name2().

** Corrected a segfault when setting an empty gnutls_priority_t
at gnutls_priority_set().

** Use gettext 0.17 which updates m4/lib-*.m4 macros.
Fixes a problem with spurious -L/usr/lib additions.

** API and ABI modifications:
gnutls_x509_crt_get_subject_alt_name2: 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.8.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.1.8.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/20071210/35bc736b/attachment.pgp>

From simon at josefsson.org  Mon Dec 10 15:42:30 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Dec 2007 15:42:30 +0100
Subject: [gnutls-dev] GnuTLS 2.1.8
In-Reply-To: <87odcyrd8z.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 10 Dec 2007 12:38:20 +0100")
References: <87odcyrd8z.fsf@mocca.josefsson.org>
Message-ID: <87k5nmd31l.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Consider this a release candidate for version 2.2.  I plan to release
> this on December 13th if there are no serious reports.

I've branched off gnutls_2_2_x from 2.1.8, in case you are wondering why
git master (soon) contains gnutls 2.3.x stuff.

/Simon



From simon at josefsson.org  Mon Dec 10 17:13:22 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Dec 2007 17:13:22 +0100
Subject: [gnutls-dev] Libtasn1 1.2
Message-ID: <87sl2a34v1.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.2 (released 2007-12-10)
- Update gnulib files.

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

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

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.5MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.2.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.2.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.2.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.2.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

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

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

Here are the SHA-1 and SHA-224 checksums:

f423ee15405e4bc21052733f19d0abdc6f909da8  libtasn1-1.2.tar.gz
5bdcd006b46bb881939c4d6c608c2f952c0ce38a  libtasn1-1.2.tar.gz.sig

693c8298ecdc852c7c83b3477a657903d129cef8c70ec7bd6d9ffbaf  libtasn1-1.2.tar.gz
110f283c2d3d91cc1ab7105461f313cfd113df5be648c878ba2c1fa5  libtasn1-1.2.tar.gz.sig

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

From simon at josefsson.org  Fri Dec 14 12:08:02 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Dec 2007 12:08:02 +0100
Subject: Mailing list moved!
Message-ID: <87abodfsa5.fsf@mocca.josefsson.org>

Hi!  If everything works, this will be the first message posted through
the new mailing list address gnutls-devel at gnu.org.

The old mailing list gnutls-dev at gnupg.org is no longer used, but
messages to that address will be forwarded to the new list.  Everyone
who was subscribed to the old list should be subscribed to the new list.

This change allows bug-gnutls at gnu.org to be sent directly to the
gnutls-devel list, fixes archiving of PGP/MIME signed messages, makes
sure that non-subscribed people can post to the list, and possibly fixes
other issues that I don't recall now as well.

/Simon




From simon at josefsson.org  Fri Dec 14 13:31:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Dec 2007 13:31:42 +0100
Subject: GnuTLS 2.2.0
Message-ID: <87fxy5a24x.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.2.0.

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

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

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

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

Major changes compared to the v2.0 branch:

* SRP support aligned with newly published RFC 5054.

* OpenPGP support aligned with newly published RFC 5081.

* Support for DSA2 keys.

* Support for Camellia cipher.

* Support for Opaque PRF Input extension.

* PKCS#8 parser now handle DSA keys.

* Change from GPLv2 to GPLv3 for command-line tools, libgnutls-extra,
etc.  Notice that liblzo2 2.02 is licensed under GPLv2 only.  Earlier
versions, such as 2.01 which is included with GnuTLS, is available under
GPLv2 or later.  If this incompatibility causes problems, we recommend
you to disable LZO using --without-lzo.  LZO compression is not a
standard TLS compression algorithm, so the impact should be minimal.

* Functions for disabling record protocol padding.
Works around bugs on Nokia/Ericsson phones.

* New functions gnutls_priority_set() for setting cipher priorities easily.
Priorities like "COMPAT" also enables other work arounds, such as
disabling padding.

* Other minor improvements and bug fixes.

Minor changes compared to the latest v2.1.8 release candidate:

* Update internal copy of libtasn1 to version 1.2.

* Certtool --verify-chain now handle inputs larger than 64kb.
This fixes the self-test "rsa-md5-collision" under MinGW+Wine with
recent versions of libgcrypt.  The problem was that Wine with the
libgcrypt RNG generates huge amounts of debugging output.

* Translation updates.
Added Dutch translation.  Updated Polish and Swedish translation.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

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

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

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

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

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

f0024abb61ee07e2ad00943098a439e0e7656742  gnutls-2.2.0.tar.bz2

d446c0fe0888b734f533692d1108af53f90ee5a128625efb05a8e908  gnutls-2.2.0.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

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

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

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

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

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

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

1821cab6dbe81ba1e7eda92f4debd3a789949205  gnutls-2.2.0.exe

7572f61e07eded8e1c96f8ffed3f26991384dcd18995f657962fc972  gnutls-2.2.0.exe

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20071214/5ba2ee42/attachment.pgp>

From alon.barlev at gmail.com  Fri Dec 14 18:49:54 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 14 Dec 2007 19:49:54 +0200
Subject: gnutls-2.2.0 - self link issue
Message-ID: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>

Hello Simon,

Every few revision we have the same issue with GnuTLS.
It self-link itself with system library and not the package library.

Every time we fix it differently... But I think it worth you fixing it properly.

Thanks!
http://bugs.gentoo.org/show_bug.cgi?id=202269
http://bugs.gentoo.org/show_bug.cgi?id=166518
http://bugs.gentoo.org/show_bug.cgi?id=147800
http://bugs.gentoo.org/show_bug.cgi?id=91012
http://bugs.gentoo.org/show_bug.cgi?id=79232

Best Regards,
Alon Bar-Lev.




From ametzler at downhill.at.eu.org  Sat Dec 15 20:04:06 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 15 Dec 2007 20:04:06 +0100
Subject: GPLv3 (was: [gnutls-dev] GnuTLS 2.1.7)
In-Reply-To: <87abox9lkd.fsf@mocca.josefsson.org>
References: <87abox9lkd.fsf@mocca.josefsson.org>
Message-ID: <20071215190406.GD4502@downhill.g.la>

On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
[...]
> 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.
[...]

I know this is a litle bit late. I have gone over Debian/main eyeing
packages depending on libgnutls13 and checking whether they link
against libgnutls-extra or libgnutls-openssl.

Most of the packages listing GPLv2 as license seem to be false
positives or a least unclear (freewheeling, gkrellm, kildclient,
sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
package that actually will lose its SSL functionality, since it is
GPLv2.

Please note that that I have not checked whether license conflicts of
this form would exist

program links against libgnutls-extra or libgnutls-openssl.
program also links agains libfoo, and libfoo is not GPLv3 compatible.

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  Sun Dec 16 10:19:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 16 Dec 2007 10:19:00 +0100
Subject: GPLv3
In-Reply-To: <20071215190406.GD4502@downhill.g.la> (Andreas Metzler's message
	of "Sat, 15 Dec 2007 20:04:06 +0100")
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
Message-ID: <871w9n6lq3.fsf@mocca.josefsson.org>

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

> On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
> [...]
>> 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.
> [...]
>
> I know this is a litle bit late.

If serious problems arise, I don't think it is totally impossible to go
back to GPLv2.  However, that requires _serious_ problems.
libgnutls-extra doesn't contain any (as far as I know) widely used
features right now, so I do expect the problems to be minor.  Most can
probably be resolved by not linking to libgnutls-extra.  Doing the
license switch will trigger analysis like the one you did, which we
really appreciate.  If we never make the switch, nobody will bother to
do a good analysis.

> I have gone over Debian/main eyeing packages depending on libgnutls13
> and checking whether they link against libgnutls-extra or
> libgnutls-openssl.

I'd expect this to be quite few libraries.  For my information, how do
you generate a list of packages that link to libgnutls-extra?  I'd like
to analyze those packages further myself.

> Most of the packages listing GPLv2 as license seem to be false
> positives or a least unclear (freewheeling, gkrellm, kildclient,
> sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
> package that actually will lose its SSL functionality, since it is
> GPLv2.

Can't they just stop using libgnutls-extra?  Lynx doesn't support
OpenPGP or SRP authentication anyway, does it?  I don't see why it needs
to link with libgnutls-extra.

Generally, it would be interesting to know if there are _any_ widely
deployed tools that truly depend on the libgnutls-extra features.

> Please note that that I have not checked whether license conflicts of
> this form would exist
>
> program links against libgnutls-extra or libgnutls-openssl.
> program also links agains libfoo, and libfoo is not GPLv3 compatible.

I'd expect there are some of these...

/Simon




From alon.barlev at gmail.com  Sun Dec 16 10:12:26 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 16 Dec 2007 11:12:26 +0200
Subject: GPLv3 (was: [gnutls-dev] GnuTLS 2.1.7)
In-Reply-To: <20071215190406.GD4502@downhill.g.la>
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
Message-ID: <9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>

We have this also:
http://bugs.gentoo.org/show_bug.cgi?id=202381

On 12/15/07, Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
> [...]
> > 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.
> [...]
>
> I know this is a litle bit late. I have gone over Debian/main eyeing
> packages depending on libgnutls13 and checking whether they link
> against libgnutls-extra or libgnutls-openssl.
>
> Most of the packages listing GPLv2 as license seem to be false
> positives or a least unclear (freewheeling, gkrellm, kildclient,
> sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
> package that actually will lose its SSL functionality, since it is
> GPLv2.
>
> Please note that that I have not checked whether license conflicts of
> this form would exist
>
> program links against libgnutls-extra or libgnutls-openssl.
> program also links agains libfoo, and libfoo is not GPLv3 compatible.
>
> 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'
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>




From simon at josefsson.org  Mon Dec 17 12:05:14 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Dec 2007 12:05:14 +0100
Subject: gnutls-2.2.0 - self link issue
In-Reply-To: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
	(Alon Bar-Lev's message of "Fri, 14 Dec 2007 19:49:54 +0200")
References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
Message-ID: <87lk7t60ph.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> Hello Simon,
>
> Every few revision we have the same issue with GnuTLS.
> It self-link itself with system library and not the package library.
>
> Every time we fix it differently... But I think it worth you fixing it
> properly.

This looks like the same issue as:

http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2439

However, that one was fixed.

Can you reproduce this problem outside of the gentoo ebuild system?
Does gentoo run gettextize/autoconf/automake/libtoolize or replace any
m4 files from the upstream version, or something similar?

The important thing, I think, is to not run autopoint with any version
older than 0.17.  Then you'll get the incorrect lib-*.m4 files.

> Thanks!
> http://bugs.gentoo.org/show_bug.cgi?id=202269
> http://bugs.gentoo.org/show_bug.cgi?id=166518
> http://bugs.gentoo.org/show_bug.cgi?id=147800
> http://bugs.gentoo.org/show_bug.cgi?id=91012
> http://bugs.gentoo.org/show_bug.cgi?id=79232

I think the best way to resolve this problem is to give a recipe to
reproduce the problem outside of the gentoo build system.  Then I can
debug it and possibly report any bugs to upstream tools (gettext,
libtool, etc).

/Simon




From simon at josefsson.org  Mon Dec 17 12:27:29 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Dec 2007 12:27:29 +0100
Subject: GPLv3
In-Reply-To: <9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>
	(Alon Bar-Lev's message of "Sun, 16 Dec 2007 11:12:26 +0200")
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>
Message-ID: <87d4t55zoe.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> We have this also:
> http://bugs.gentoo.org/show_bug.cgi?id=202381

See the release notes:

http://permalink.gmane.org/gmane.network.gnutls.general/1020

 * Change from GPLv2 to GPLv3 for command-line tools, libgnutls-extra,
 etc.  Notice that liblzo2 2.02 is licensed under GPLv2 only.  Earlier
 versions, such as 2.01 which is included with GnuTLS, is available under
 GPLv2 or later.  If this incompatibility causes problems, we recommend
 you to disable LZO using --without-lzo.  LZO compression is not a
 standard TLS compression algorithm, so the impact should be minimal.

Btw, I just talked with Markus and he were going to release a new
version of liblzo under GPLv2+GPLv3 early next year.

Still, I'm not sure if it makes sense for GnuTLS to enable LZO
compression by default any more.  It is not a standard TLS compression
algorithm.  What do people think?  It would also be interesting to
compare it with LZMA, which has gained some popularity lately:

http://www.7-zip.org/sdk.html
http://tukaani.org/lzma/

Btw, liblzo* has rather few reverse dependencies on Debian, so except
for gnutls liblzo isn't that widely used.  Dropping it might save space
on most installation.

I suggest that we disable LZO by default in the next releases unless
someone protests.  It would still be a supported feature though.

/Simon




From simon at josefsson.org  Mon Dec 17 12:49:12 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Dec 2007 12:49:12 +0100
Subject: TLS compression (was: Re: GPLv3)
In-Reply-To: <87d4t55zoe.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 17 Dec 2007 12:27:29 +0100")
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>
	<87d4t55zoe.fsf@mocca.josefsson.org>
Message-ID: <87zlw94k3r.fsf_-_@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Still, I'm not sure if it makes sense for GnuTLS to enable LZO
> compression by default any more.  It is not a standard TLS compression
> algorithm.  What do people think?  It would also be interesting to
> compare it with LZMA, which has gained some popularity lately:
>
> http://www.7-zip.org/sdk.html
> http://tukaani.org/lzma/
>
> Btw, liblzo* has rather few reverse dependencies on Debian, so except
> for gnutls liblzo isn't that widely used.  Dropping it might save space
> on most installation.

I found this quote:

http://www.ddj.com/architect/184405581

  Igor Pavlov is the developer behind the amazing 7-Zip compressor,
  which has always been available under the GPL. Igor has now created a
  separate LZMA SDK, which implements his compression algorithm in a way
  that makes it suitable for embedded applications.

  On the SDK web page, Igor says that the LZMA code can decompress up to
  1 MB/s on a 100 MHz ARM, MIPS, or other RISC CPU. The memory
  requirements for decompression are as low as 8-23 KB, and the code may
  take up as little as 2-8KB.

  This sounds like a great piece of work for embedded developers. Up
  until now, the best library out there for this community has been LZO,
  which has a few problems that hold it back. Perhaps Igor's product
  will now be the go-to library for this community.

Perhaps we should do some work in this area...

Does anyone know of any real-world benchmarks of TLS compression?  I'd
guess that network traffic compression have different properties than
file compression.  I would guess that network traffic actually is easier
to compress than files, on average; a lot of network traffic are verbose
text protocols.

/Simon




From simon at josefsson.org  Mon Dec 17 14:09:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Dec 2007 14:09:39 +0100
Subject: having devel releases
In-Reply-To: <200712160932.05971.n.mavrogiannopoulos@gmail.com> (Nikos
	Mavrogiannopoulos's message of "Sun, 16 Dec 2007 09:32:05 +0200")
References: <200712160932.05971.n.mavrogiannopoulos@gmail.com>
Message-ID: <87r6hl4gdo.fsf@mocca.josefsson.org>

Moving this to gnutls-devel in case others like to chime in...

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

> Hello Simon,
>  While thinking to do some fixes for the 2.2.x branch I noticed that it is 
> quite cumbersome to maintain two releases, one stable and one development. I 
> also felt that while fixing stuff for the 2.0.x release before. That is 
> because every fix has to be commited in both and verified in both, which is 
> time-consuming and time I no longer have.
>
> Instead of that I'd propose to use a main "stable" release and branches around 
> it for big and intrusive changes. I.e a DTLS modification would be a branch 
> of the main release, which will be merged once the modifications will become 
> stable. On such big merges we could also increase the minor release number to 
> indicate such feature addition (and thus it would be that the first few 
> releases of a minor number change will be the "unstable" branch).
>
> What do you think about that? Have you also noticed this problem?

Yeah, it is problematic to maintain several branches... I think a good
solution is to never spend time on back-porting anything except for
security problems, and to make sure we have speedy new stable releases
so that important non-security fixes don't get delayed.

What do you think about this approach?

Phase 0.  Chaotic development.  Separate branches, e.g., for new
features like DTLS, PKCS#11.  Releases could be made from this branch if
necessary, and to get feedback from testers.  No coordination with
anyone is necessary for this.  Anyone can take the lead to implement
some feature and make releases.

Phase 1.  Stable release candidate ('master' git branch).  This means
bumping the minor release number.  We also make official "unstable"
releases from time to time, so people can test everything more easily.
This is loosely coupled with the timing of the stable branch, we only
add things from the chaotic development step during the first two months
after a stable release.  If the feature requires a lot of fixes after
that time, it is probably not ready, and should be removed from the
stable release candidate branch.

Phase 2.  Stable branch (gnutls_x_y_z).  Released every 4 months with
one months of testing were nothing is changed except for critical (or
security? to avoid back-porting) bugs.  Once released it is never
updated except for security bugs.  The intention is to forget about the
branch once it has been released, and avoid spending time on the boring
back-porting of fixes.

Thus a rolling timeline will look like:

First day of Month 1:

  Stable release.

Second day of Month 1:
...
Last day of Month 2:

  Pull in things from chaotic development branches to 'master'.  Minor
  projects is directly added to 'master'.  Make releases (possibly
  automated), early testing.

Month 3:

  No new features added to 'master', they must be done on branches.
  Evaluation of release-worthiness of the how the entire package
  interacts with the new features.  Stuff that needs a lot of fixes are
  reverted and have to wait for the next cycle.  Intention is to have
  slow rate of non-important fixes here, otherwise it suggests the
  feature isn't ready yet.

First day of Month 4:
...
Last day of Month 4:

  Branch off stable release from master.  Only serious problems are
  fixed on the branch.  If there are several or non-trivial patches for
  a new feature, consider whether to pull the feature entirely because
  it is not ready yet.  Don't bother to back-port any non-security fixes
  that are discovered on the master branch, they will have to wait for
  the next cycle.

First day of Month 5:

  Stable release.

What do you think?

/Simon




From ametzler at downhill.at.eu.org  Mon Dec 17 20:06:37 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 17 Dec 2007 20:06:37 +0100
Subject: GPLv3
In-Reply-To: <871w9n6lq3.fsf@mocca.josefsson.org>
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<871w9n6lq3.fsf@mocca.josefsson.org>
Message-ID: <20071217190637.GB4515@downhill.g.la>

On 2007-12-16 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> I'd expect this to be quite few libraries.  For my information, how do
> you generate a list of packages that link to libgnutls-extra?
[...]

Brute force shellscripting. Unpack all packages depending on
libgnutls13 (that is only direct linking.) and check ldd output.

ametzler at merkel:/tmp/gnut$ zcat /org/ftp.root/debian/dists/unstable/*/binary-ia64/Packages.gz | grep-dctrl -FDepends -sFilename libgnutls13 | sed -e 's_^Filename: _/org/ftp.root/debian/_' > rdep-files
ametzler at merkel:/tmp/gnut$ for i in `cat rdep-files ` ; do dpkg -x $i `basename $i _ia64.deb` ; done
ametzler at merkel:/tmp/gnut$ for i in `find -type f -print` ; do if ldd "$i" 2>/dev/null | grep -q libgnutls- ; then echo $i ; fi; done > /tmp/reffer.gnutls 2>&1 

> > Most of the packages listing GPLv2 as license seem to be false
> > positives or a least unclear (freewheeling, gkrellm, kildclient,
> > sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
> > package that actually will lose its SSL functionality, since it is
> > GPLv2.

> Can't they just stop using libgnutls-extra?

I was not aiming to dig in to depths of code, and just checked
licenses.  I have submitted bug reports against the unclear packages,
asking for clarification or a possible switch to GPLv2+. gkrellm is
already resolved.

#456433 #456440 #456439 #456442

> Lynx doesn't support OpenPGP or SRP authentication anyway, does it?
> I don't see why it needs to link with libgnutls-extra.
[...]

lynx is using the OpenSSL compatibility layer. I do not know why it
links against -extra, too.
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 n.mavrogiannopoulos at gmail.com  Mon Dec 17 23:05:46 2007
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 18 Dec 2007 00:05:46 +0200
Subject: having devel releases
In-Reply-To: <87r6hl4gdo.fsf@mocca.josefsson.org>
References: <200712160932.05971.n.mavrogiannopoulos@gmail.com>
	<87r6hl4gdo.fsf@mocca.josefsson.org>
Message-ID: <200712180005.46890.n.mavrogiannopoulos@gmail.com>

On Monday 17 December 2007, Simon Josefsson wrote:

> Yeah, it is problematic to maintain several branches... I think a good
> solution is to never spend time on back-porting anything except for
> security problems, and to make sure we have speedy new stable releases
> so that important non-security fixes don't get delayed.
>
> What do you think about this approach?
> Phase 0.  Chaotic development.  Separate branches, e.g., for new
> features like DTLS, PKCS#11.  Releases could be made from this branch if
> necessary, and to get feedback from testers.  No coordination with
> anyone is necessary for this.  Anyone can take the lead to implement
> some feature and make releases.

So (to make it clear to me) there would be several branches:
gnutls_2_2_x_with_dtls
gnutls_2_2_x_with_pkcs11
gnutls_2_2_x==HEAD

> Phase 1.  Stable release candidate ('master' git branch).  This means
> bumping the minor release number. 

So the next stable would be 2.3.x under this scheme?

> We also make official "unstable" 
> releases from time to time, so people can test everything more easily.

Named by the name of the branch?

> This is loosely coupled with the timing of the stable branch, we only
> add things from the chaotic development step during the first two months
> after a stable release.  If the feature requires a lot of fixes after
> that time, it is probably not ready, and should be removed from the
> stable release candidate branch.

What I noticed in the changes I did last months, is that majority of the 
additions to the code were small bug fixes, and small improvements. Those 
shouldn't need to go to a separate branch or wait for the chaotic development 
to become ordered. They could be commited directly to the (stable) say 
gnutls_2_2_x branch, and released regularly.

I'd propose, as an addition to your proposal, to have different branches for 
big changes as you mentioned, but keep the small (and unintrusive) changes 
and additions to the main (stable) branch. So something like, say, the fix 
you did to certtool for unlimited size of certificate chains, wouldn't 
require a full release cycle, or a wait for a DTLS branch (if any) to 
stabilize - which might take several months.

> Phase 2.  Stable branch (gnutls_x_y_z).  Released every 4 months with
> one months of testing were nothing is changed except for critical (or
> security? to avoid back-porting) bugs.  Once released it is never
> updated except for security bugs.  The intention is to forget about the
> branch once it has been released, and avoid spending time on the boring
> back-porting of fixes.

This is unavoidable since bug fixes will need to be backported eventually if 
they are over some level of importance. 

> Last day of Month 2:
>   Pull in things from chaotic development branches to 'master'.  Minor
>   projects is directly added to 'master'.  Make releases (possibly
>   automated), early testing.

So the master will be unstable like what we have now? If it is unstable I 
think it might be better not to cope with timetables. We could have a new 
release once an "unstable" new branch has reached a testing level. This will 
avoid having slow-paced branches to stall releases and we can take our time 
for big changes. (I currently can only work on a very slow-paced way thus I'd 
avoid any timetables).

regards,
Nikos







From simon at josefsson.org  Tue Dec 18 10:25:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Dec 2007 10:25:07 +0100
Subject: gnutls-2.2.0 - self link issue
In-Reply-To: <87lk7t60ph.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 17 Dec 2007 12:05:14 +0100")
References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
	<87lk7t60ph.fsf@mocca.josefsson.org>
Message-ID: <877ijcjqx8.fsf@mocca.josefsson.org>

I tried to reproduce the problem, but couldn't.  This is on a debian
machine, with old gnutls in /usr/lib.  I unpacked gnutls-2.2.0 and ran
./configure && make.  The link command for libgnutls-extra.la was:

/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -g -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -L/usr/local/lib -lopencdk -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -lz -R/usr/local/lib   -version-info 27:1:1  -Wl,--version-script=./libgnutls-extra.vers  -o libgnutls-extra.la -rpath /usr/local/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la  ../lgl/liblgnu.la ../lib/libgnutls.la minilzo/libminilzo.la 

which resulted for libgnutls-extra.so in:

gcc -std=gnu99 -shared  .libs/gnutls_extra.o .libs/gnutls_openpgp.o .libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a ../lgl/.libs/liblgnu.a minilzo/.libs/libminilzo.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/jas/src/gnutls-2.2.0/lib/.libs -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib /usr/local/lib/libopencdk.so -lz /usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so ../lib/.libs/libgnutls.so  -Wl,--version-script=./libgnutls-extra.vers -Wl,-soname -Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1

That looks correct to me.

There were some claims that libtool relinked the library during 'make
install', and indeed it does:

 /bin/sh ../libtool --mode=install /usr/bin/install -c  'libgnutls-extra.la' '/usr/local/lib/libgnutls-extra.la'
libtool: install: warning: relinking `libgnutls-extra.la'
(cd /home/jas/src/gnutls-2.2.0/libextra; /bin/sh ../libtool  --tag=CC --mode=relink gcc -std=gnu99 -g -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -L/usr/local/lib -lopencdk -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -lz -R/usr/local/lib -version-info 27:1:1 -Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath /usr/local/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la minilzo/libminilzo.la )  

Which results in:

gcc -std=gnu99 -shared  .libs/gnutls_extra.o .libs/gnutls_openpgp.o .libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a ../lgl/.libs/liblgnu.a minilzo/.libs/libminilzo.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib -lopencdk -lz -lgcrypt -lgpg-error -lgnutls  -Wl,--version-script=./libgnutls-extra.vers -Wl,-soname -Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1

This also looks correct to me.

So, I cannot reproduce the problem.  I need a recipe to reproduce this
outside of the gentoo ebuild system to be able to debug this further.

/Simon

Simon Josefsson <simon at josefsson.org> writes:

> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>
>> Hello Simon,
>>
>> Every few revision we have the same issue with GnuTLS.
>> It self-link itself with system library and not the package library.
>>
>> Every time we fix it differently... But I think it worth you fixing it
>> properly.
>
> This looks like the same issue as:
>
> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2439
>
> However, that one was fixed.
>
> Can you reproduce this problem outside of the gentoo ebuild system?
> Does gentoo run gettextize/autoconf/automake/libtoolize or replace any
> m4 files from the upstream version, or something similar?
>
> The important thing, I think, is to not run autopoint with any version
> older than 0.17.  Then you'll get the incorrect lib-*.m4 files.
>
>> Thanks!
>> http://bugs.gentoo.org/show_bug.cgi?id=202269
>> http://bugs.gentoo.org/show_bug.cgi?id=166518
>> http://bugs.gentoo.org/show_bug.cgi?id=147800
>> http://bugs.gentoo.org/show_bug.cgi?id=91012
>> http://bugs.gentoo.org/show_bug.cgi?id=79232
>
> I think the best way to resolve this problem is to give a recipe to
> reproduce the problem outside of the gentoo build system.  Then I can
> debug it and possibly report any bugs to upstream tools (gettext,
> libtool, etc).
>
> /Simon
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From simon at josefsson.org  Tue Dec 18 11:28:15 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Dec 2007 11:28:15 +0100
Subject: GPLv3 migration reminder
In-Reply-To: <20071218032409.GB3032@schmorp.de> (Marc Lehmann's message of
	"Tue, 18 Dec 2007 04:24:09 +0100")
References: <20070628222440.GI20021@fencepost.gnu.org>
	<87k5tj875p.fsf@mocca.josefsson.org>
	<20071218032409.GB3032@schmorp.de>
Message-ID: <87prx4cn5s.fsf@mocca.josefsson.org>

Marc Lehmann <schmorp at schmorp.de> writes:

> On Mon, Jul 02, 2007 at 11:52:02AM +0200, Simon Josefsson <simon at josefsson.org> wrote:
>> 1) GnuTLS (libgnutls-extra) has a dependency on the LZO library which is
>> only available under the GPLv2:
>
> <shameless plug> There is always lzf, vastly simpler, smaller, cetrianly
> feature-starved, but available under 2-clause BSD, GPLv2 and _later_
> licenses (http://liblzf.schmorp.de), and the author is doubtlessly flexible
> about the license.

Thanks for the pointer.  The trade-offs for TLS compression is slightly
different than for file compression -- the most important factor is
probably de-compression speed and memory footprint.  LZO claims to have
good properties here.  How does lzf stand?

It would be interesting to run tests on a few different compression
libraries to see how they compare for network compression...

/Simon




From simon at josefsson.org  Tue Dec 18 11:44:23 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Dec 2007 11:44:23 +0100
Subject: TLS compression
In-Reply-To: <e646fda30712171107q5678618agdd4503dd1e083be8@mail.gmail.com>
	(John Brooks's message of "Mon, 17 Dec 2007 12:07:50 -0700")
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>
	<87d4t55zoe.fsf@mocca.josefsson.org>
	<87zlw94k3r.fsf_-_@mocca.josefsson.org>
	<e646fda30712171107q5678618agdd4503dd1e083be8@mail.gmail.com>
Message-ID: <87lk7scmew.fsf@mocca.josefsson.org>

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

> Assuming the compression is done prior to encryption (I can't recall if it
> is or not),

Right, compression is done before encryption in TLS.  (RFC 3749)

> pretty much any major compression format and especially powerful ones
> like LZMA will compress most things to incredible levels. Standard
> text (i.e. most protocols, websites, etc) tends to compress extremely
> well - i've seen bzip2 reduce hundreds of megabytes of text files to
> 1/4th of their original size, and LZMA is generally regarded as doing
> even better.

Ok.

> One concern would be that LZMA compression is pretty slow. It takes some
> serious CPU effort - it might put a pretty hefty load on the compressing
> side in higher speed connections.

The quote below suggests otherwise, but perhaps it was comparing the
situation against even worse algorithms.  I think the trade-offs are
different for network compression than for file compression.

Right now, the only standard compression algorithm besides DEFLATE is
LZS which is patented as far as I know.  It would be interesting to
compare and develop a free and better alternative..

/Simon

> If the compression is done after encryption, the benefit will be much less
> noticable. Obviously encrypted data will be fairly evenly distributed, so it
> won't be able to compress much.
>
>  - John
>
> On Dec 17, 2007 4:49 AM, Simon Josefsson <simon at josefsson.org> wrote:
>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>> > Still, I'm not sure if it makes sense for GnuTLS to enable LZO
>> > compression by default any more.  It is not a standard TLS compression
>> > algorithm.  What do people think?  It would also be interesting to
>> > compare it with LZMA, which has gained some popularity lately:
>> >
>> > http://www.7-zip.org/sdk.html
>> > http://tukaani.org/lzma/
>> >
>> > Btw, liblzo* has rather few reverse dependencies on Debian, so except
>> > for gnutls liblzo isn't that widely used.  Dropping it might save space
>> > on most installation.
>>
>> I found this quote:
>>
>> http://www.ddj.com/architect/184405581
>>
>>  Igor Pavlov is the developer behind the amazing 7-Zip compressor,
>>  which has always been available under the GPL. Igor has now created a
>>  separate LZMA SDK, which implements his compression algorithm in a way
>>  that makes it suitable for embedded applications.
>>
>>  On the SDK web page, Igor says that the LZMA code can decompress up to
>>  1 MB/s on a 100 MHz ARM, MIPS, or other RISC CPU. The memory
>>  requirements for decompression are as low as 8-23 KB, and the code may
>>  take up as little as 2-8KB.
>>
>>  This sounds like a great piece of work for embedded developers. Up
>>  until now, the best library out there for this community has been LZO,
>>  which has a few problems that hold it back. Perhaps Igor's product
>>  will now be the go-to library for this community.
>>
>> Perhaps we should do some work in this area...
>>
>> Does anyone know of any real-world benchmarks of TLS compression?  I'd
>> guess that network traffic compression have different properties than
>> file compression.  I would guess that network traffic actually is easier
>> to compress than files, on average; a lot of network traffic are verbose
>> text protocols.
>>
>> /Simon
>>
>>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>>
>
>
>
> -- 
> - John




From smurf at smurf.noris.de  Tue Dec 18 11:57:01 2007
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Tue, 18 Dec 2007 11:57:01 +0100
Subject: TLS compression
In-Reply-To: <87lk7scmew.fsf@mocca.josefsson.org>
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<9e0cf0bf0712160112y31a519cfj9be53252b9dd95d0@mail.gmail.com>
	<87d4t55zoe.fsf@mocca.josefsson.org>
	<87zlw94k3r.fsf_-_@mocca.josefsson.org>
	<e646fda30712171107q5678618agdd4503dd1e083be8@mail.gmail.com>
	<87lk7scmew.fsf@mocca.josefsson.org>
Message-ID: <20071218105701.GF9751@kiste.smurf.noris.de>

Hi,

"John Brooks" <aspecialj at gmail.com> writes:
> Assuming the compression is done prior to encryption (I can't recall if it
> is or not),
> 
Doing it the other way 'round would be ... somewhat stupid.

For rather large values of "stupid".

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
We all know that no one understands anything that isn't funny.




From schmorp at schmorp.de  Wed Dec 19 02:12:34 2007
From: schmorp at schmorp.de (Marc Lehmann)
Date: Wed, 19 Dec 2007 02:12:34 +0100
Subject: GPLv3 migration reminder
In-Reply-To: <87prx4cn5s.fsf@mocca.josefsson.org>
References: <20070628222440.GI20021@fencepost.gnu.org>
	<87k5tj875p.fsf@mocca.josefsson.org>
	<20071218032409.GB3032@schmorp.de>
	<87prx4cn5s.fsf@mocca.josefsson.org>
Message-ID: <20071219011234.GB4541@schmorp.de>

On Tue, Dec 18, 2007 at 11:28:15AM +0100, Simon Josefsson <simon at josefsson.org> wrote:
> different than for file compression -- the most important factor is
> probably de-compression speed and memory footprint.  LZO claims to have
> good properties here.  How does lzf stand?

Much faster and much less memory used (for compression, just the
hashtable, for decompression no extra memory is required except for
input and output buffers and the code is very small), except when lzo
offers a pure assembly implementation (liblzf has a similar but simpler
representation, but is only available as portable C code).

Of course, compressed size is larger for liblzf than for about any lzo
mode, but thats the trade-off.

For example, a tar of my /bin (10506240 bytes), compression, on my amd64:

   time lzop -1 <x.tar |wc -c
   6329754
   user    0m0.204s

   time lzf <x.tar |wc -c
   6714002
   user    0m0.132s

decompression:

   lzop: 0m0.056s
   lzf:  0m0.048s

this is not a very good test, as buffering and other things only the
commandline tools do have quite some overhead, but gives a rough
indication.

lzf is tunable for speed and compression in various ways, the above is the
default (medium speed).

lzf is especially nice for repeated compressions (its not a stream
compressor), as it doesn't need to set up its internal state.

> It would be interesting to run tests on a few different compression
> libraries to see how they compare for network compression...

Every benchmark is always sooo surprising :->

What is not clear to me is how gnutls would use liblzf, purely as
in-memory cache, or would it also use it for network traffic (in which
case, wouldn't it have to support lzo for backwards compatibility, and
would it then not just be able to talk to itself?)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\




From simon at josefsson.org  Wed Dec 19 13:04:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Dec 2007 13:04:47 +0100
Subject: GPLv3 migration reminder
In-Reply-To: <20071219011234.GB4541@schmorp.de> (Marc Lehmann's message of
	"Wed, 19 Dec 2007 02:12:34 +0100")
References: <20070628222440.GI20021@fencepost.gnu.org>
	<87k5tj875p.fsf@mocca.josefsson.org>
	<20071218032409.GB3032@schmorp.de>
	<87prx4cn5s.fsf@mocca.josefsson.org>
	<20071219011234.GB4541@schmorp.de>
Message-ID: <87y7bqhov4.fsf@mocca.josefsson.org>

Marc Lehmann <schmorp at schmorp.de> writes:

> On Tue, Dec 18, 2007 at 11:28:15AM +0100, Simon Josefsson <simon at josefsson.org> wrote:
>> different than for file compression -- the most important factor is
>> probably de-compression speed and memory footprint.  LZO claims to have
>> good properties here.  How does lzf stand?
>
> Much faster and much less memory used (for compression, just the
> hashtable, for decompression no extra memory is required except for
> input and output buffers and the code is very small), except when lzo
> offers a pure assembly implementation (liblzf has a similar but simpler
> representation, but is only available as portable C code).
>
> Of course, compressed size is larger for liblzf than for about any lzo
> mode, but thats the trade-off.

Interesting, thanks for info.

>    lzop: 0m0.056s
>    lzf:  0m0.048s
>
> this is not a very good test, as buffering and other things only the
> commandline tools do have quite some overhead, but gives a rough
> indication.

Right, that's why I was interested in doing some real TLS-related
benchmarks...

> What is not clear to me is how gnutls would use liblzf, purely as
> in-memory cache, or would it also use it for network traffic (in which
> case, wouldn't it have to support lzo for backwards compatibility, and
> would it then not just be able to talk to itself?)

Network traffic.  Currently DEFLATE (libz) is supported by TLS, and
there is one patented alternative (LZS) specified.  We support LZO too,
even though it isn't standardized.  I don't think LZO in TLS has any
wide deployment, and in any case, there is nothing that says we can't
support both LZO and LZF.  Doing so would make it easier to perform
benchmarks.

Still, I guess that there are more higher priority projects in GnuTLS..
but compress benchmarks seems like an interesting thing to do.

/Simon




From simon at josefsson.org  Wed Dec 19 13:09:28 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Dec 2007 13:09:28 +0100
Subject: If you are reading this via gmane.org
Message-ID: <87tzmehonb.fsf@mocca.josefsson.org>

Just a note to people reading this list via gmane.org: right now Gmane
only post messages addressed to gnutls-dev at gnupg.org.  Messages sent to
gnutls-devel at gnu.org (the new address) are discarded.

I've asked the gmane admins to fix this but no response so far..

http://thread.gmane.org/gmane.discuss/11389

Ergo, you may want to subscribe to the list, or check the list archives
to avoid missing anything:

http://lists.gnu.org/archive/html/gnutls-devel/2007-12/threads.html

/Simon




From simon at josefsson.org  Wed Dec 19 14:33:53 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Dec 2007 14:33:53 +0100
Subject: GPLv3
In-Reply-To: <20071217190637.GB4515@downhill.g.la> (Andreas Metzler's message
	of "Mon, 17 Dec 2007 20:06:37 +0100")
References: <87abox9lkd.fsf@mocca.josefsson.org>
	<20071215190406.GD4502@downhill.g.la>
	<871w9n6lq3.fsf@mocca.josefsson.org>
	<20071217190637.GB4515@downhill.g.la>
Message-ID: <87prx2hkqm.fsf@mocca.josefsson.org>

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

> On 2007-12-16 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> I'd expect this to be quite few libraries.  For my information, how do
>> you generate a list of packages that link to libgnutls-extra?
> [...]
>
> Brute force shellscripting. Unpack all packages depending on
> libgnutls13 (that is only direct linking.) and check ldd output.
>
> ametzler at merkel:/tmp/gnut$ zcat /org/ftp.root/debian/dists/unstable/*/binary-ia64/Packages.gz | grep-dctrl -FDepends -sFilename libgnutls13 | sed -e 's_^Filename: _/org/ftp.root/debian/_' > rdep-files
> ametzler at merkel:/tmp/gnut$ for i in `cat rdep-files ` ; do dpkg -x $i `basename $i _ia64.deb` ; done
> ametzler at merkel:/tmp/gnut$ for i in `find -type f -print` ; do if ldd "$i" 2>/dev/null | grep -q libgnutls- ; then echo $i ; fi; done > /tmp/reffer.gnutls 2>&1 

Thanks.

>> > Most of the packages listing GPLv2 as license seem to be false
>> > positives or a least unclear (freewheeling, gkrellm, kildclient,
>> > sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
>> > package that actually will lose its SSL functionality, since it is
>> > GPLv2.
>
>> Can't they just stop using libgnutls-extra?
>
> I was not aiming to dig in to depths of code, and just checked
> licenses.  I have submitted bug reports against the unclear packages,
> asking for clarification or a possible switch to GPLv2+. gkrellm is
> already resolved.
>
> #456433 #456440 #456439 #456442

Interesting, ssmtp uses libgnutls-openssl.  The copyright seems indeed
rather unclear, so until it has been clarified, I don't think we should
take any action to re-license anything.

>> Lynx doesn't support OpenPGP or SRP authentication anyway, does it?
>> I don't see why it needs to link with libgnutls-extra.
> [...]
>
> lynx is using the OpenSSL compatibility layer. I do not know why it
> links against -extra, too.

It doesn't seem to link to extra here:

mocca:/home/jas# ldd /usr/bin/lynx
        linux-gate.so.1 =>  (0xffffe000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7f0c000)
        libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7ed0000)
        libgnutls-openssl.so.13 => /usr/lib/libgnutls-openssl.so.13 (0xb7ec4000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7e4d000)
        libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7e1b000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7cce000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7cb9000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7cb5000)
        libtasn1.so.3 => /usr/local/lib/libtasn1.so.3 (0xb7ca5000)
        libgcrypt.so.11 => /usr/local/lib/libgcrypt.so.11 (0xb7c3d000)
        libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0xb7c39000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7c21000)
        /lib/ld-linux.so.2 (0xb7f2c000)
mocca:/home/jas# 

/Simon




From nmav at gnutls.org  Thu Dec 20 20:19:08 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Dec 2007 21:19:08 +0200
Subject: opencdk under LGPL
Message-ID: <200712202119.08436.nmav@gnutls.org>

Thanks to Timo Schulz and Free Software Foundation some parts of the opencdk 
library are now available under LGPL. I used those parts to create a gnutls 
library with openpgp support (in the main LGPL library). You can check the 
gnutls_2_2_x_with_opencdk branch if you want to test it.

In this version only the included LGPL opencdk library is used.

regards,
Nikos




From simon at josefsson.org  Fri Dec 21 08:59:06 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 21 Dec 2007 08:59:06 +0100
Subject: opencdk under LGPL
In-Reply-To: <200712202119.08436.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Thu, 20 Dec 2007 21:19:08 +0200")
References: <200712202119.08436.nmav@gnutls.org>
Message-ID: <878x3oiilx.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Thanks to Timo Schulz and Free Software Foundation some parts of the opencdk 
> library are now available under LGPL. I used those parts to create a gnutls 
> library with openpgp support (in the main LGPL library). You can check the 
> gnutls_2_2_x_with_opencdk branch if you want to test it.
>
> In this version only the included LGPL opencdk library is used.

Interesting!  How will this interact with upstream opencdk releases?
Will upstream opencdk be re-licensed to LGPL?

/Simon




From twoaday at gmx.net  Fri Dec 21 10:21:25 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 21 Dec 2007 10:21:25 +0100
Subject: opencdk under LGPL
In-Reply-To: <878x3oiilx.fsf@mocca.josefsson.org>
References: <200712202119.08436.nmav@gnutls.org>
	<878x3oiilx.fsf@mocca.josefsson.org>
Message-ID: <476B8595.2020300@gmx.net>

Simon Josefsson wrote:

>> In this version only the included LGPL opencdk library is used.
> 
> Interesting!  How will this interact with upstream opencdk releases?
> Will upstream opencdk be re-licensed to LGPL?

Only the code portions which are used in GnuTLS were re-licensed
under LGPL, but some other code which bases on GPG is still GPL
and thus the library cannot switch to LGPL.

But some issues remain and need to be discussed.


	Timo




From simon at josefsson.org  Fri Dec 21 10:53:30 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 21 Dec 2007 10:53:30 +0100
Subject: opencdk under LGPL
In-Reply-To: <476B8595.2020300@gmx.net> (Timo Schulz's message of "Fri, 21 Dec
	2007 10:21:25 +0100")
References: <200712202119.08436.nmav@gnutls.org>
	<878x3oiilx.fsf@mocca.josefsson.org> <476B8595.2020300@gmx.net>
Message-ID: <87ejdgcr1h.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>>> In this version only the included LGPL opencdk library is used.
>> 
>> Interesting!  How will this interact with upstream opencdk releases?
>> Will upstream opencdk be re-licensed to LGPL?
>
> Only the code portions which are used in GnuTLS were re-licensed
> under LGPL, but some other code which bases on GPG is still GPL
> and thus the library cannot switch to LGPL.
>
> But some issues remain and need to be discussed.

Ok.  It seems bad if we duplicate code but slightly modify it.  Perhaps
the code can be modularized in opencdk, so opencdk consists of one GPL
part and one LGPL part?  Then GnuTLS could just depend on the LGPL part.

Also, at least in debian, opencdk has only gnutls, gabber and centerim
as reverse dependencies, and I suspect gabber+centerim are just mistaken
dependencies (they probably use gnutls not opencdk, I guess).  So that
means gnutls is the only opencdk consumer in practice.  So maybe opencdk
could just be merged with gnutls?

Just some ideas..

/Simon




From schmorp at schmorp.de  Thu Dec 20 03:39:36 2007
From: schmorp at schmorp.de (Marc Lehmann)
Date: Thu, 20 Dec 2007 03:39:36 +0100
Subject: GPLv3 migration reminder
In-Reply-To: <87y7bqhov4.fsf@mocca.josefsson.org>
References: <20070628222440.GI20021@fencepost.gnu.org>
	<87k5tj875p.fsf@mocca.josefsson.org>
	<20071218032409.GB3032@schmorp.de>
	<87prx4cn5s.fsf@mocca.josefsson.org>
	<20071219011234.GB4541@schmorp.de>
	<87y7bqhov4.fsf@mocca.josefsson.org>
Message-ID: <20071220023936.GE13814@schmorp.de>

On Wed, Dec 19, 2007 at 01:04:47PM +0100, Simon Josefsson <simon at josefsson.org> wrote:
> Right, that's why I was interested in doing some real TLS-related
> benchmarks...

Count me in :)

> Network traffic.  Currently DEFLATE (libz) is supported by TLS, and
> there is one patented alternative (LZS) specified.  We support LZO too,
> even though it isn't standardized.  I don't think LZO in TLS has any
> wide deployment, and in any case, there is nothing that says we can't
> support both LZO and LZF.  Doing so would make it easier to perform
> benchmarks.

I'd say supporting lzf AND lzo makes little sense, as its yet
another incompatible format (even if its autonegotiated, ensuring
interoperability), and your problem seems to have been licensing with lzo.

I'd recommend staying with liblzo (it is far more flexible) if you have
to support it anyways, but you can of course do what you want, I won't
complain if you find you want (my) liblzf in gnutls, I'd be honored :->

(I would also say that network bandwidth usually should take priority over
(reasonable) compression times, and liblzf is certainly on the speed side,
not on the data compression side, of the spectrum).

> Still, I guess that there are more higher priority projects in GnuTLS..

Yeah, but thats what the TODO list is for. In rxvt-unicode, for example,
whatever you put on the TODO list instead of tackling it immediately will
almost cetrainly stay there for years.

> but compress benchmarks seems like an interesting thing to do.

Go for it, and tell me any results, thank you :)

If you do them, the default is probably good, but you can look at lzfP.h for
configuration options, like:

   HLOG        - for memory usage, lower is less memory
   VERY_FAST   - enabled "medium mode", the default, which is good for binary,
                 somewhat bad for text
   ULTRA_FAST  - make it even faster, and quite a bit worse, ratio-wise.

One could even play with the hash function, which is critical, but the
default will certainly do.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\




From twoaday at gmx.net  Fri Dec 21 13:32:33 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 21 Dec 2007 13:32:33 +0100
Subject: opencdk under LGPL
In-Reply-To: <87ejdgcr1h.fsf@mocca.josefsson.org>
References: <200712202119.08436.nmav@gnutls.org>	<878x3oiilx.fsf@mocca.josefsson.org>
	<476B8595.2020300@gmx.net> <87ejdgcr1h.fsf@mocca.josefsson.org>
Message-ID: <476BB261.4040102@gmx.net>

Simon Josefsson wrote:

>> But some issues remain and need to be discussed.
> 
> Ok.  It seems bad if we duplicate code but slightly modify it.  Perhaps
> the code can be modularized in opencdk, so opencdk consists of one GPL
> part and one LGPL part?  Then GnuTLS could just depend on the LGPL part.

Actually, this is exactly what I proposed to Nikos. I guess it would
make sense to have a new build target to build the LGPL-part only.
And this stripped library could be directly used by GnuTLS, as you
also suggested.


> means gnutls is the only opencdk consumer in practice.  So maybe opencdk
> could just be merged with gnutls?

Well, the major problem with opencdk is, that it needs lots of changes
but my timetable does not permit this right now. Maybe the situation
will improve later and then I could do more "advertising".


	Timo




From simon at josefsson.org  Fri Dec 21 23:31:38 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 21 Dec 2007 23:31:38 +0100
Subject: gnutls-2.2.0 - self link issue
In-Reply-To: <9e0cf0bf0712211410j2fc0af44udfc294d94c1eb81b@mail.gmail.com>
	(Alon Bar-Lev's message of "Sat, 22 Dec 2007 00:10:07 +0200")
References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
	<87lk7t60ph.fsf@mocca.josefsson.org>
	<877ijcjqx8.fsf@mocca.josefsson.org>
	<9e0cf0bf0712211410j2fc0af44udfc294d94c1eb81b@mail.gmail.com>
Message-ID: <87ejdfsmr9.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 12/18/07, Simon Josefsson <simon at josefsson.org> wrote:
>> So, I cannot reproduce the problem.  I need a recipe to reproduce this
>> outside of the gentoo ebuild system to be able to debug this further.
>
> Sorry for the delay...
>
> While having gnutls-2.0.4 installed.
>
> $ tar -xf gnutls-2.2.0.tar.bz2
> $ cd gnutls-2.2.0
> $ ./configure
> $ make install DESTDIR=`pwd`/xxx
> $ ldd xxx/usr/local/lib/libgnutls-extra.so
>         linux-gate.so.1 =>  (0xb7fc7000)
>         libopencdk.so.10 => /usr/lib/libopencdk.so.10 (0xb7f7a000)
>         liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb7f5c000)
>         libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7ee2000)
>         libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7edd000)
>         libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7e63000)
>         libc.so.6 => /lib/libc.so.6 (0xb7d33000)
>         libz.so.1 => /lib/libz.so.1 (0xb7d1f000)
>         libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7d0e000)
>         /lib/ld-linux.so.2 (0x80000000)

That's exactly what I needed, I can now reproduce the problem.  It is
late today and I'm leaving for the holidays early tomorrow, but I may be
able to debug it on my laptop offline.

Btw, is only libgnutls-extra.so affected for you?  The programs appear
to be linked properly here, even those that are linked with
libgnutls-extra.so.  I suspect the bug is in libextra/Makefile.am in how
it interacts with libtool.

jas at mocca:~/gnutls-2.2.0$ ldd xxx/usr/local/bin/psktool
        linux-gate.so.1 =>  (0xffffe000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb7e89000)
        libgnutls-extra.so.26 => /usr/lib/libgnutls-extra.so.26 (0xb7e7e000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7e15000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7e11000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7cc4000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7cb5000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7ca0000)
        libopencdk.so.10 => /usr/lib/libopencdk.so.10 (0xb7c7d000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7c65000)
        /lib/ld-linux.so.2 (0xb7f12000)
jas at mocca:~/gnutls-2.2.0$ ldd xxx/usr/local/lib/libgnutls.so
        linux-gate.so.1 =>  (0xffffe000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7f2f000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7ec7000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7ec2000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d75000)
        /lib/ld-linux.so.2 (0x80000000)
jas at mocca:~/gnutls-2.2.0$ ldd xxx/usr/local/lib/libgnutls-openssl.so
        linux-gate.so.1 =>  (0xffffe000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7eaa000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7ea6000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7e2e000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ce1000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7cd2000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7cba000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7ca5000)
        /lib/ld-linux.so.2 (0x80000000)
jas at mocca:~/gnutls-2.2.0$ ldd xxx/usr/local/lib/libgnutls-extra.so
        linux-gate.so.1 =>  (0xffffe000)
        libopencdk.so.10 => /usr/lib/libopencdk.so.10 (0xb7f0a000)
        liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb7eea000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7e81000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7e7d000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7e06000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7cb9000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7ca4000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7c94000)
        libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7c7c000)
        /lib/ld-linux.so.2 (0x80000000)
jas at mocca:~/gnutls-2.2.0$ 

Thanks,
/Simon




From alon.barlev at gmail.com  Fri Dec 21 23:39:29 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 22 Dec 2007 00:39:29 +0200
Subject: gnutls-2.2.0 - self link issue
In-Reply-To: <87ejdfsmr9.fsf@mocca.josefsson.org>
References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
	<87lk7t60ph.fsf@mocca.josefsson.org>
	<877ijcjqx8.fsf@mocca.josefsson.org>
	<9e0cf0bf0712211410j2fc0af44udfc294d94c1eb81b@mail.gmail.com>
	<87ejdfsmr9.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0712211439qbd5811eq6b0f60a3b58c9453@mail.gmail.com>

On 12/22/07, Simon Josefsson <simon at josefsson.org> wrote:
> That's exactly what I needed, I can now reproduce the problem.  It is
> late today and I'm leaving for the holidays early tomorrow, but I may be
> able to debug it on my laptop offline.

Great!

> Btw, is only libgnutls-extra.so affected for you?  The programs appear
> to be linked properly here, even those that are linked with
> libgnutls-extra.so.  I suspect the bug is in libextra/Makefile.am in how
> it interacts with libtool.

No... openssl is also:
xxx/usr/local/lib/libgnutls-openssl.so:
        linux-gate.so.1 =>  (0xb7fd8000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7fa0000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7f26000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7f21000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7ea8000)
        libc.so.6 => /lib/libc.so.6 (0xb7d77000)
        libz.so.1 => /lib/libz.so.1 (0xb7d63000)
        /lib/ld-linux.so.2 (0x80000000)




From alon.barlev at gmail.com  Fri Dec 21 23:10:07 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 22 Dec 2007 00:10:07 +0200
Subject: gnutls-2.2.0 - self link issue
In-Reply-To: <877ijcjqx8.fsf@mocca.josefsson.org>
References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com>
	<87lk7t60ph.fsf@mocca.josefsson.org>
	<877ijcjqx8.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0712211410j2fc0af44udfc294d94c1eb81b@mail.gmail.com>

On 12/18/07, Simon Josefsson <simon at josefsson.org> wrote:
> So, I cannot reproduce the problem.  I need a recipe to reproduce this
> outside of the gentoo ebuild system to be able to debug this further.

Sorry for the delay...

While having gnutls-2.0.4 installed.

$ tar -xf gnutls-2.2.0.tar.bz2
$ cd gnutls-2.2.0
$ ./configure
$ make install DESTDIR=`pwd`/xxx
$ ldd xxx/usr/local/lib/libgnutls-extra.so
        linux-gate.so.1 =>  (0xb7fc7000)
        libopencdk.so.10 => /usr/lib/libopencdk.so.10 (0xb7f7a000)
        liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb7f5c000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7ee2000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7edd000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7e63000)
        libc.so.6 => /lib/libc.so.6 (0xb7d33000)
        libz.so.1 => /lib/libz.so.1 (0xb7d1f000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7d0e000)
        /lib/ld-linux.so.2 (0x80000000)

Best Regards,
Alon Bar-Lev.