From simon at josefsson.org Tue Sep 9 14:30:48 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 14:30:48 +0200 Subject: [Help-gnutls] Using LGPLv3+ license for libgnutls? Message-ID: <87y721pklj.fsf@mocca.josefsson.org> RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead of using LGPLv3+. The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash is also said to contain GPLv2-only code. Are there other reasons not to use LGPLv3+? I recall hearing about policies that mandate LGPLv2.1+ in some projects, for example the core libraries in GNOME, but I cannot find any reference to this out there. Anyone? /Simon From home at alexhudson.com Tue Sep 9 14:53:05 2008 From: home at alexhudson.com (Alex Hudson) Date: Tue, 09 Sep 2008 13:53:05 +0100 Subject: [Help-gnutls] Using LGPLv3+ license for libgnutls? In-Reply-To: <87y721pklj.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> Message-ID: <48C671B1.20301@alexhudson.com> Hi Simon, Simon Josefsson wrote: > RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead > of using LGPLv3+. > > The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash > is also said to contain GPLv2-only code. > > Are there other reasons not to use LGPLv3+? > There are a number of applications out there that are GPLv2-only, including the project I work on (http://www.bongo-project.org/). OpenSSL isn't available for those who can't relicense their projects, so not having GnuTLS be available would be a big blow. > I recall hearing about policies that mandate LGPLv2.1+ in some projects, > for example the core libraries in GNOME, but I cannot find any reference > to this out there. Anyone? > IIRC, Gtk+ hackers have talked about moving to LGPLv3, but nothing has actually been agreed. Cheers, Alex. From simon at josefsson.org Tue Sep 9 15:54:00 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 15:54:00 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <48C671B1.20301@alexhudson.com> (Alex Hudson's message of "Tue, 09 Sep 2008 13:53:05 +0100") References: <87y721pklj.fsf@mocca.josefsson.org> <48C671B1.20301@alexhudson.com> Message-ID: <87d4jdpgqv.fsf@mocca.josefsson.org> Alex Hudson writes: > Hi Simon, > > Simon Josefsson wrote: >> RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead >> of using LGPLv3+. >> >> The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash >> is also said to contain GPLv2-only code. >> >> Are there other reasons not to use LGPLv3+? >> > > There are a number of applications out there that are GPLv2-only, > including the project I work on > (http://www.bongo-project.org/). OpenSSL isn't available for those who > can't relicense their projects, so not having GnuTLS be available > would be a big blow. Thanks for the information. If you know of more GPLv2-only projects that use GnuTLS, that would be useful to know. Btw, Bongo looks relatively new, could you share any insight why you chose a GPLv2-only license? It looks bound to create problems sooner or later. >> I recall hearing about policies that mandate LGPLv2.1+ in some projects, >> for example the core libraries in GNOME, but I cannot find any reference >> to this out there. Anyone? >> > > IIRC, Gtk+ hackers have talked about moving to LGPLv3, but nothing has > actually been agreed. Ok. So maybe they actually don't have a LGPLv2.1+ policy. Thanks, Simon From home at alexhudson.com Tue Sep 9 17:26:10 2008 From: home at alexhudson.com (Alex Hudson) Date: Tue, 09 Sep 2008 16:26:10 +0100 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <87d4jdpgqv.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <48C671B1.20301@alexhudson.com> <87d4jdpgqv.fsf@mocca.josefsson.org> Message-ID: <48C69592.5050902@alexhudson.com> Simon Josefsson wrote: > Thanks for the information. If you know of more GPLv2-only projects > that use GnuTLS, that would be useful to know. > > Btw, Bongo looks relatively new, could you share any insight why you > chose a GPLv2-only license? It looks bound to create problems sooner or > later. > It's not our choice, I'm afraid - we're a fork of the Hula Project, so Novell has a large amount of copyright interest in the code, and it's politically difficult to change that now (as they sold the rights to that business to a proprietary software company). Our current project guidance is that contributions to Bongo are GPLv2+, and parts of Bongo are now fully under that license, but it will take time (a couple of years probably) before we've reached the stage where no old code is being used. I suspect there will probably be other projects in the same situation. >> IIRC, Gtk+ hackers have talked about moving to LGPLv3, but nothing has >> actually been agreed. >> > > Ok. So maybe they actually don't have a LGPLv2.1+ policy. > Well, I believe the policy is to be LGPL rather than GPL, but I don't think that the version discussion has actually happened yet. Thanks, Alex. From simon at josefsson.org Tue Sep 9 18:01:23 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 18:01:23 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080909153708.GD14713@manyfish.co.uk> (Joe Orton's message of "Tue, 9 Sep 2008 16:37:08 +0100") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> Message-ID: <87y721nwa4.fsf@mocca.josefsson.org> Joe Orton writes: > On Tue, Sep 09, 2008 at 02:30:48PM +0200, Simon Josefsson wrote: >> RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead >> of using LGPLv3+. >> >> The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash >> is also said to contain GPLv2-only code. >> >> Are there other reasons not to use LGPLv3+? > > Here's a list of packages from Fedora Raw Hide which link against GnuTLS > and have license tags indicating GPLv2-only licensing: > > aria2-0.12.0-5.fc10.src.rpm - GPLv2 > climm-0.6.3-1.fc10.src.rpm - GPLv2 > cups-1.3.8-5.fc10.src.rpm - GPLv2 > ekg2-0.2-0.4.rc1.fc10.src.rpm - GPLv2 > gobby-0.4.6-1.fc10.src.rpm - GPLv2 > hardinfo-0.4.2.3-6.fc10.src.rpm - GPLv2 > jd-2.0.1-0.2.beta080901.fc10.src.rpm - GPLv2 > snort-2.8.1-5.fc10.src.rpm - GPLv2 > sobby-0.4.4-5.fc10.src.rpm - GPLv2 > xfce4-mailwatch-plugin-1.0.1-10.fc10.src.rpm - GPLv2 > > (Note that this list is not necessarily complete since it won't include > packages which have not yet had their License tags audited.) Thanks for the list! I tried to do some systematic searches, but the debian copyright information tends to be incorrect (not mentioning versions) or difficult to parse. I recognize cups, snort and ekg, and they are fairly well known. /Simon From dkg at fifthhorseman.net Tue Sep 9 19:46:17 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Sep 2008 13:46:17 -0400 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <87y721nwa4.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue\, 09 Sep 2008 18\:01\:23 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> Message-ID: <87sks98b6e.fsf@squeak.fifthhorseman.net> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: > I tried to do some systematic searches, but the debian copyright > information tends to be incorrect (not mentioning versions) or difficult > to parse. This is sadly true. Automatic resolution of this sort of question would be much easier if the machine-readable debian/copyright proposal was more widely-adopted: http://wiki.debian.org/Proposals/CopyrightFormat > I recognize cups, snort and ekg, and they are fairly well known. fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the debian copyright info, so it's possilbe that the fedora tags are wrong on that package: [0 dkg at squeak ~]$ grep -A5 ^License: /usr/share/doc/libobby-0.4-1/copyright License: This library is written by the 0x539 dev group and is licensed under the GNU General Public License (GPL) version 2 or any later version. A copy of the license is included in the distribution. [0 dkg at squeak ~]$ And cups appears to be ambiguous as far as the GPL'ed bits (though the LGPL'ed bits are pretty clearly V2-only): [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright INTRODUCTION The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided under the GNU General Public License ("GPL") and GNU Library General Public License ("LGPL"), Version 2, with exceptions for Apple operating systems and the OpenSSL toolkit. A copy of the exceptions and licenses follow this introduction. [0 dkg at squeak ~]$ I couldn't come up with an automated way to pull the answers to these questions out of debian automatically either :( --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From davefx at gmail.com Wed Sep 10 07:59:36 2008 From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=) Date: Wed, 10 Sep 2008 07:59:36 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080909205951.GA18961@manyfish.co.uk> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> Message-ID: But I don't catch what is the problem: a proprietary licensed product can be dinamically linked to a LGPL3 library. And, as far as I know (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 product can still be dinamically (or even statically) linked with a LGPL3 library. We are not talking about GPLv3. It's LGPLv3. Perhaps, the problem would be the GPL'd parts of gnutls... -- David Mar?n Carre?o 2008/9/9 Joe Orton : > On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >> >> > I tried to do some systematic searches, but the debian copyright >> > information tends to be incorrect (not mentioning versions) or difficult >> > to parse. >> >> This is sadly true. Automatic resolution of this sort of question >> would be much easier if the machine-readable debian/copyright proposal >> was more widely-adopted: >> >> http://wiki.debian.org/Proposals/CopyrightFormat > > We have such a standard agreed at Fedora but the hard work is really in > auditing N thousand packages to meet it. > >> > I recognize cups, snort and ekg, and they are fairly well known. >> >> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >> debian copyright info, so it's possilbe that the fedora tags are wrong >> on that package: > > I agree, good catch, thanks; I've filed a bug to get this fixed in > Fedora. > >> And cups appears to be ambiguous as far as the GPL'ed bits (though the >> LGPL'ed bits are pretty clearly V2-only): >> >> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >> INTRODUCTION >> >> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >> under the GNU General Public License ("GPL") and GNU Library >> General Public License ("LGPL"), Version 2, with exceptions for >> Apple operating systems and the OpenSSL toolkit. A copy of the >> exceptions and licenses follow this introduction. > > Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I > would say that since the code is explicit about being licensed per the > terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. > > If anybody thinks this is important to clarify I can chase it with the > Fedora licensing guys. > > Regards, Joe > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From simon at josefsson.org Wed Sep 10 09:28:29 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 09:28:29 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: ("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Wed, 10 Sep 2008 07:59:36 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> Message-ID: <878wu0o3xe.fsf@mocca.josefsson.org> The license compatibility matrix is useful, see: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility The problem is for GPLv2-only projects that wants to use a LGPLv3 library. Using LGPLv3+ also has consequences for projects that wants to copy code from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not something that happens widely enough to care about as far as I am aware. If anyone knows of significant code re-use from gnutls, let me know. /Simon "David Mar?n Carre?o" writes: > But I don't catch what is the problem: a proprietary licensed product > can be dinamically linked to a LGPL3 library. And, as far as I know > (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 > product can still be dinamically (or even statically) linked with a > LGPL3 library. > > We are not talking about GPLv3. It's LGPLv3. > > Perhaps, the problem would be the GPL'd parts of gnutls... > > > -- > David Mar?n Carre?o > > > 2008/9/9 Joe Orton : >> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >>> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >>> >>> > I tried to do some systematic searches, but the debian copyright >>> > information tends to be incorrect (not mentioning versions) or difficult >>> > to parse. >>> >>> This is sadly true. Automatic resolution of this sort of question >>> would be much easier if the machine-readable debian/copyright proposal >>> was more widely-adopted: >>> >>> http://wiki.debian.org/Proposals/CopyrightFormat >> >> We have such a standard agreed at Fedora but the hard work is really in >> auditing N thousand packages to meet it. >> >>> > I recognize cups, snort and ekg, and they are fairly well known. >>> >>> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >>> debian copyright info, so it's possilbe that the fedora tags are wrong >>> on that package: >> >> I agree, good catch, thanks; I've filed a bug to get this fixed in >> Fedora. >> >>> And cups appears to be ambiguous as far as the GPL'ed bits (though the >>> LGPL'ed bits are pretty clearly V2-only): >>> >>> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >>> INTRODUCTION >>> >>> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >>> under the GNU General Public License ("GPL") and GNU Library >>> General Public License ("LGPL"), Version 2, with exceptions for >>> Apple operating systems and the OpenSSL toolkit. A copy of the >>> exceptions and licenses follow this introduction. >> >> Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I >> would say that since the code is explicit about being licensed per the >> terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. >> >> If anybody thinks this is important to clarify I can chase it with the >> Fedora licensing guys. >> >> Regards, Joe >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From simon at josefsson.org Wed Sep 10 10:24:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 10:24:37 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <87sks98b6e.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 09 Sep 2008 13:46:17 -0400") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> Message-ID: <87ljy0mmre.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: > >> I tried to do some systematic searches, but the debian copyright >> information tends to be incorrect (not mentioning versions) or difficult >> to parse. > > This is sadly true. Automatic resolution of this sort of question > would be much easier if the machine-readable debian/copyright proposal > was more widely-adopted: > > http://wiki.debian.org/Proposals/CopyrightFormat I have changed one of my debian packages to use it, and will do the same for another. Thanks for the pointer. > And cups appears to be ambiguous as far as the GPL'ed bits (though the > LGPL'ed bits are pretty clearly V2-only): > > [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright > INTRODUCTION > > The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided > under the GNU General Public License ("GPL") and GNU Library > General Public License ("LGPL"), Version 2, with exceptions for > Apple operating systems and the OpenSSL toolkit. A copy of the > exceptions and licenses follow this introduction. > [0 dkg at squeak ~]$ > > I couldn't come up with an automated way to pull the answers to these > questions out of debian automatically either :( Looking at the source code headers in CUPS indicate a somewhat confusing situation. At least some of the files definitely just reference version 2 though. /Simon From bortzmeyer at nic.fr Wed Sep 10 14:01:13 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Sep 2008 14:01:13 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <878wu0o3xe.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> Message-ID: <20080910120113.GA11677@nic.fr> On Wed, Sep 10, 2008 at 09:28:29AM +0200, Simon Josefsson wrote a message of 94 lines which said: > The problem is for GPLv2-only projects that wants to use a LGPLv3 > library. :-( My case: http://echoping.sourceforge.net/ Since echoping has the OpenSSL exception, switching GNUTLS to LGPLv3 would mean dropping GNUTLS support, just to please the FSF lawyers. From simon at josefsson.org Wed Sep 10 14:10:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 14:10:04 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080910120113.GA11677@nic.fr> (Stephane Bortzmeyer's message of "Wed, 10 Sep 2008 14:01:13 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> Message-ID: <874p4otd5v.fsf@mocca.josefsson.org> Stephane Bortzmeyer writes: > On Wed, Sep 10, 2008 at 09:28:29AM +0200, > Simon Josefsson wrote > a message of 94 lines which said: > >> The problem is for GPLv2-only projects that wants to use a LGPLv3 >> library. > > :-( > > My case: http://echoping.sourceforge.net/ > > Since echoping has the OpenSSL exception, switching GNUTLS to LGPLv3 > would mean dropping GNUTLS support, just to please the FSF lawyers. Is echoping licensed under GPLv2 or GPLv2-or-later? I can't find anything conclusive in the echoping sources (probably something you want to fix :)). GPLv2-or-later with OpenSSL exception is compatible with LGPLv3 if I understand correctly. Anyway, it seems we have gathered plenty of arguments that probably will delay re-licensing for some time. /Simon From bortzmeyer at nic.fr Wed Sep 10 14:17:41 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Sep 2008 14:17:41 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <874p4otd5v.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> <874p4otd5v.fsf@mocca.josefsson.org> Message-ID: <20080910121741.GA14911@nic.fr> On Wed, Sep 10, 2008 at 02:10:04PM +0200, Simon Josefsson wrote a message of 27 lines which said: > Is echoping licensed under GPLv2 or GPLv2-or-later? v2 only > I can't find anything conclusive in the echoping sources (probably > something you want to fix :)). COPYING says: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 To me, in the absence of other mention, it means v2 only. COPYING later says: Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. And the magical sentence "any later version" does not appear in the source code (only in autotools-generated files). From simon at josefsson.org Wed Sep 10 14:38:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 14:38:37 +0200 Subject: [Help-gnutls] Re: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080910121741.GA14911@nic.fr> (Stephane Bortzmeyer's message of "Wed, 10 Sep 2008 14:17:41 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> <874p4otd5v.fsf@mocca.josefsson.org> <20080910121741.GA14911@nic.fr> Message-ID: <87hc8orx9u.fsf@mocca.josefsson.org> Stephane Bortzmeyer writes: > On Wed, Sep 10, 2008 at 02:10:04PM +0200, > Simon Josefsson wrote > a message of 27 lines which said: > >> Is echoping licensed under GPLv2 or GPLv2-or-later? > > v2 only > >> I can't find anything conclusive in the echoping sources (probably >> something you want to fix :)). > > COPYING says: > > GNU GENERAL PUBLIC LICENSE > Version 2, June 1991 > > To me, in the absence of other mention, it means v2 only. > > COPYING later says: > > Each version is given a distinguishing version number. If the Program > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. > > And the magical sentence "any later version" does not appear in the > source code (only in autotools-generated files). I didn't see a specific version number mentioned in the _program_ (there are no license headers in the *.c files). The license continues: If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. FWIW, adding a license headers to each file (and making sure it specify the version of the GPL) would help to clarify the intended license. Including a verbatim copy of the GPL doesn't mean the program is automatically licensed under the GPL. There needs to be some statement that binds the program with the license. Anyway, I think we have established a long list of GPLv2-only projects that use GnuTLS that needs to be studied more closely before we make any decision to move to LGPLv3+. /Simon From beuc at beuc.net Sat Sep 13 15:09:12 2008 From: beuc at beuc.net (Sylvain Beucler) Date: Sat, 13 Sep 2008 15:09:12 +0200 Subject: [Help-gnutls] Multi-domain certificate request Message-ID: <20080913130912.GA19482@perso.beuc.net> Hi, I'd like to issue a certificate request for multiple domains / virtual hosts, as described here: http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly I didn't find how to do it using certtool. Is there something similar to openssl's "subjectAltName"? I found a reference to "dns_name" but it only accepts a single value. Thanks, -- Sylvain From darkdemun at gmail.com Sun Sep 14 04:54:34 2008 From: darkdemun at gmail.com (darkdemun) Date: Sun, 14 Sep 2008 14:54:34 +1200 Subject: [Help-gnutls] Debugging Message-ID: <11d59200809131954wbe082ebvf1f9a4eab3fbdf6@mail.gmail.com> Hi, sorry if this isn't the place to ask, but whenever i try to debug my app which uses gnutls, gdb just hangs at "setting breakpoints" has this happened to any of you, and if so how do you fix it? (i'm using mingw) -- Cain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart at scopeport.org Sun Sep 14 14:06:55 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Sun, 14 Sep 2008 14:06:55 +0200 Subject: [Help-gnutls] GNUTLS in handshake procedure Message-ID: <1221394015.2873.10.camel@sundaysister> Hello everyone, i am using GNUTLS in a server i am currently writing on. I am planning to implement a handshaking procedure: 1. Client requests TLS or non-TLS encryption. 2. Server responds if packets are accepted and if TLS is available. 3. Client sends data corresponding to reply from server. Can i just place the gnutls_handshake() when TLS is available and client chose to use TLS? Could there be sync problem because gnutls_handshake() is not the first thing that is done in the socket connection/conversation? Please, i need your experience. :) Thank you! So long Lennart From aspecialj at gmail.com Sun Sep 14 18:40:26 2008 From: aspecialj at gmail.com (John Brooks) Date: Sun, 14 Sep 2008 10:40:26 -0600 Subject: [Help-gnutls] GNUTLS in handshake procedure In-Reply-To: <1221394015.2873.10.camel@sundaysister> References: <1221394015.2873.10.camel@sundaysister> Message-ID: As long as the handshake is called in the proper order (client must speak first, which means client must initiate the handshake), it doesn't matter when that happens during a connection's lifetime. The server does need to be expecting it, or it would try to handle the data normally instead of passing it to gnutls for handshaking. Provided both ends are expecting it when it happens, and the client goes first, you won't have any problems. This is generally referred to as 'starttls'; it's a great way to support both SSL and non-SSL connections, but care needs to be taken to avoid MITM attacks stripping the SSL (for example, an attacker faking a response from the server stating that SSL is not supported, to force your connection to remain unencrypted), and to ensure that nothing private is sent before the SSL connection starts. - John Brooks On Sun, Sep 14, 2008 at 6:06 AM, Lennart Koopmann wrote: > Hello everyone, > > i am using GNUTLS in a server i am currently writing on. I am planning > to implement a handshaking procedure: > > 1. Client requests TLS or non-TLS encryption. > 2. Server responds if packets are accepted and if TLS is available. > 3. Client sends data corresponding to reply from server. > > Can i just place the gnutls_handshake() when TLS is available and client > chose to use TLS? Could there be sync problem because gnutls_handshake() > is not the first thing that is done in the socket > connection/conversation? > > Please, i need your experience. :) > > Thank you! > > So long > Lennart > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From lennart at scopeport.org Mon Sep 15 15:13:10 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Mon, 15 Sep 2008 15:13:10 +0200 Subject: [Help-gnutls] GNUTLS in handshake procedure Message-ID: <1221484390.2765.10.camel@sundaysister> Hello John, thank you very much! That seems to be what i planned to do. Good to hear that it should make no problems. I will try it today. The MITM attack should be no problem, because the client is forced to use GNUTLS when the user specified it. There is no possibilty to send unencrypted data after the handshaking procedure if useGNUTLS is set to true. :) Thank you! So long Lennart Am Sonntag, den 14.09.2008, 10:40 -0600 schrieb John Brooks: > As long as the handshake is called in the proper order (client must > speak first, which means client must initiate the handshake), it > doesn't matter when that happens during a connection's lifetime. The > server does need to be expecting it, or it would try to handle the > data normally instead of passing it to gnutls for handshaking. > Provided both ends are expecting it when it happens, and the client > goes first, you won't have any problems. > > This is generally referred to as 'starttls'; it's a great way to > support both SSL and non-SSL connections, but care needs to be taken > to avoid MITM attacks stripping the SSL (for example, an attacker > faking a response from the server stating that SSL is not supported, > to force your connection to remain unencrypted), and to ensure that > nothing private is sent before the SSL connection starts. > > - John Brooks From nmav at gnutls.org Mon Sep 15 23:06:02 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Sep 2008 00:06:02 +0300 Subject: [Help-gnutls] Multi-domain certificate request In-Reply-To: <20080913130912.GA19482@perso.beuc.net> References: <20080913130912.GA19482@perso.beuc.net> Message-ID: <48CECE3A.2070407@gnutls.org> Sylvain Beucler wrote: > Hi, > > I'd like to issue a certificate request for multiple domains / virtual > hosts, as described here: > http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly > > I didn't find how to do it using certtool. Is there something similar > to openssl's "subjectAltName"? > > I found a reference to "dns_name" but it only accepts a single value. As far as I remember the option to adding multiple dns names was never added to certtool so far. regards, Nikos From simon at josefsson.org Tue Sep 16 00:22:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 00:22:04 +0200 Subject: [Help-gnutls] GnuTLS 2.4.2 Message-ID: <87hc8h6odv.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.4.2. 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 distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains TLS/IA support, LZO compression -- and the OpenSSL compatibility library self tests and command line tools are distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Changes compared to the last stable release version 2.4.1: ** libgnutls: Don't crash when gnutls_credentials_set is called twice. ** libgnutls: Corrected memory leak in X.509 functions. Thanks to Colin Leroy . ** libgnutls: Fix compile error with Sun CC. ** gnutls-cli.1: Document all new parameters. Thanks to James Westby . ** tests/openssl: initialize gnutls before use. Fixes crash with libgcrypt 1.4.2. Reported by Ludovic Courtes . ** doc/: Fix texinfo markup for old texinfo versions. ** Included copy of libtasn1 is upgraded to version 1.5. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.8MB): ftp://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2 http://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2.sig http://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.4.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 79f66b47cccf9700778218b5582969255d623dc2 gnutls-2.4.2.tar.bz2 b30dc032271a052e0e5e08df2050217f4d14d37f4f5b92985a2b85da gnutls-2.4.2.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-devel mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel 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.2, libtasn1 1.5, and GnuTLS 2.4.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.4.2.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.4.2.exe.sig The checksum values for SHA-1 and SHA-224 are: 4b7b5a268386dc0393094e7517730f8e77f381d7 gnutls-2.4.2.exe fd1e6fa1abf4d3a9ab18ec83434aca55d78126f6b602452017a0adfb gnutls-2.4.2.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.4.2-1_all.deb The checksum values for SHA-1 and SHA-224 are: d9dbb77b220f48a155723b3c3b5f05067df99ee7 mingw32-gnutls_2.4.2-1_all.deb f7676ba8af27f47a2bab56c6e2e88129d6334c61eaf114c0eb5821b4 mingw32-gnutls_2.4.2-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From mahesh.nayak at gmail.com Tue Sep 16 06:18:42 2008 From: mahesh.nayak at gmail.com (Mahesh Nayak) Date: Tue, 16 Sep 2008 09:48:42 +0530 Subject: [Help-gnutls] Multi-domain certificate request In-Reply-To: <48CECE3A.2070407@gnutls.org> References: <20080913130912.GA19482@perso.beuc.net> <48CECE3A.2070407@gnutls.org> Message-ID: Hye Nikos, But then we did have "subjectAltName" on GnuTLS (I used it long time back). Cant this be used for multi domain DNS names? Cheers, Mahesh On Tue, Sep 16, 2008 at 2:36 AM, Nikos Mavrogiannopoulos wrote: > Sylvain Beucler wrote: > > Hi, > > > > I'd like to issue a certificate request for multiple domains / virtual > > hosts, as described here: > > http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly > > > > I didn't find how to do it using certtool. Is there something similar > > to openssl's "subjectAltName"? > > > > I found a reference to "dns_name" but it only accepts a single value. > > As far as I remember the option to adding multiple dns names was never > added to certtool so far. > > regards, > Nikos > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at bfk.de Tue Sep 16 09:18:52 2008 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 16 Sep 2008 09:18:52 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <82sll79ihe.fsf@mid.bfk.de> (Florian Weimer's message of "Wed, 12 Jul 2006 13:21:17 +0200") References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220121.37984.n.mavrogiannopoulos@gmail.com> <82sll79ihe.fsf@mid.bfk.de> Message-ID: <82bpyoftib.fsf@mid.bfk.de> * Florian Weimer: > It seems that gnutls_certificate_verify_peers2 sometimes returns 0 > even though no matching certificate chain has been provided. For the record, it turned out that this was a bug in my test suite, and not a problem in the GNUTLS code base. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From lennart at scopeport.org Thu Sep 18 10:09:16 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Thu, 18 Sep 2008 10:09:16 +0200 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. Message-ID: <1221725356.2856.9.camel@sundaysister> Hello everyone, i am currently implementing a handshaking procedure. Everything works fine when the client chooses not to use TLS. But when TLS is requested, the gnutls_handshake() fails. The client reports the following error: GNUTLS ERROR: A TLS packet with unexpected length was received. The server reports no error, because gnutls_handshake() seems to wait for something and just blocks. Here is some debug data (loglevel 7). --------------- Server --------------- REC[93558b8]: Expected Packet[0] Handshake(22) with length: 1 REC[93558b8]: Received Packet[0] Handshake(22) with length: 64 ASSERT: gnutls_cipher.c:204 REC[93558b8]: Decrypted Packet[0] Handshake(22) with length: 64 HSK[93558b8]: CLIENT HELLO was received [64 bytes] HSK[93558b8]: Client's version: 3.2 ASSERT: gnutls_db.c:238 EXT[93558b8]: Received extension 'CERT_TYPE/9' EXT[93558b8]: Received extension 'CERT_TYPE/9' ASSERT: ext_cert_type.c:106 ASSERT: ext_cert_type.c:106 ASSERT: ext_cert_type.c:123 HSK[93558b8]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 HSK[93558b8]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 HSK[93558b8]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 HSK[93558b8]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 HSK[93558b8]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA HSK[93558b8]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 HSK[93558b8]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 HSK[93558b8]: Selected Compression Method: NULL HSK[93558b8]: SessionID: 259495b9dd31479d1913bed547e77bfedde5f38a4f810a0c79d66b9bd9510f62 HSK[93558b8]: SERVER HELLO was send [74 bytes] REC[93558b8]: Sending Packet[0] Handshake(22) with length: 74 ASSERT: gnutls_cipher.c:204 REC[93558b8]: Sent Packet[1] Handshake(22) with length: 79 -------------------------------------- --------------- Client --------------- HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA1 HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 EXT[9bf1b58]: Sending extension CERT_TYPE HSK[9bf1b58]: CLIENT HELLO was send [64 bytes] REC[9bf1b58]: Sending Packet[0] Handshake(22) with length: 64 ASSERT: gnutls_cipher.c:204 WRITE: Will write 69 bytes to 4. WRITE: wrote 69 bytes to 4. Left 0 bytes. Total 69 bytes. 0000 - 16 03 02 00 40 01 00 00 3c 03 02 48 d2 00 41 bb 0001 - 22 27 d1 ae 80 fd 96 1c e9 81 a2 bc c4 03 95 4b 0002 - f9 10 2f 9a b7 c3 fe 5a e6 58 4a 00 00 0c 00 34 0003 - 00 46 00 3a 00 89 00 1b 00 18 01 00 00 07 00 09 0004 - 00 03 02 00 01 REC[9bf1b58]: Sent Packet[1] Handshake(22) with length: 69 READ: Got 5 bytes from 4 READ: read 5 bytes from 4 0000 - 16 03 02 00 4a RB: Have 0 bytes into buffer. Adding 5 bytes. RB: Requested 5 bytes REC[9bf1b58]: Expected Packet[0] Handshake(22) with length: 1 REC[9bf1b58]: Received Packet[0] Handshake(22) with length: 74 READ: Got 74 bytes from 4 READ: read 74 bytes from 4 0000 - 02 00 00 46 03 02 48 d2 00 41 8e 8a 8d 30 de 33 0001 - 5f 2b f8 3f 93 bf 0e e8 5f 1a 68 ed f0 d6 82 1c 0002 - cd d7 d9 97 8b 64 20 25 94 95 b9 dd 31 47 9d 19 0003 - 13 be d5 47 e7 7b fe dd e5 f3 8a 4f 81 0a 0c 79 0004 - d6 6b 9b d9 51 0f 62 00 34 00 RB: Have 5 bytes into buffer. Adding 74 bytes. RB: Requested 79 bytes ASSERT: gnutls_cipher.c:204 REC[9bf1b58]: Decrypted Packet[0] Handshake(22) with length: 74 HSK[9bf1b58]: SERVER HELLO was received [74 bytes] HSK[9bf1b58]: Server's version: 3.2 HSK[9bf1b58]: SessionID length: 32 HSK[9bf1b58]: SessionID 259495b9dd31479d1913bed547e77bfedde5f38a4f810a0c79d66b9bd9510f62 HSK[9bf1b58]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 ASSERT: gnutls_extensions.c:125 READ: Got 0 bytes from 4 READ: read 0 bytes from 4 0000 - ASSERT: gnutls_buffers.c:638 ASSERT: gnutls_record.c:909 ASSERT: gnutls_buffers.c:1150 ASSERT: gnutls_handshake.c:1043 ASSERT: gnutls_kx.c:410 ASSERT: gnutls_handshake.c:2364 -------------------------------------- As there seems to be handshaking conversation and the client starts the conversation I don't know where to search for the error. Client and server and both on the same machine, using the same GNUTLS library. Can anybody help me? Thank you! So long Lennart From simon at josefsson.org Thu Sep 18 11:19:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Sep 2008 11:19:21 +0200 Subject: [Help-gnutls] Re: Another one: A TLS packet with unexpected length was received. In-Reply-To: <1221725356.2856.9.camel@sundaysister> (Lennart Koopmann's message of "Thu, 18 Sep 2008 10:09:16 +0200") References: <1221725356.2856.9.camel@sundaysister> Message-ID: <87wsh9yfom.fsf@mocca.josefsson.org> Lennart Koopmann writes: > Hello everyone, > > i am currently implementing a handshaking procedure. Everything works > fine when the client chooses not to use TLS. But when TLS is requested, > the gnutls_handshake() fails. > > The client reports the following error: GNUTLS ERROR: A TLS packet with > unexpected length was received. > > The server reports no error, because gnutls_handshake() seems to wait > for something and just blocks. > > Here is some debug data (loglevel 7). > > --------------- Server --------------- > REC[93558b8]: Expected Packet[0] Handshake(22) with length: 1 > REC[93558b8]: Received Packet[0] Handshake(22) with length: 64 > ASSERT: gnutls_cipher.c:204 > REC[93558b8]: Decrypted Packet[0] Handshake(22) with length: 64 > HSK[93558b8]: CLIENT HELLO was received [64 bytes] > HSK[93558b8]: Client's version: 3.2 > ASSERT: gnutls_db.c:238 > EXT[93558b8]: Received extension 'CERT_TYPE/9' > EXT[93558b8]: Received extension 'CERT_TYPE/9' > ASSERT: ext_cert_type.c:106 > ASSERT: ext_cert_type.c:106 > ASSERT: ext_cert_type.c:123 > HSK[93558b8]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 > HSK[93558b8]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 > HSK[93558b8]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 > HSK[93558b8]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 > HSK[93558b8]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA > HSK[93558b8]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 > HSK[93558b8]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 > HSK[93558b8]: Selected Compression Method: NULL > HSK[93558b8]: SessionID: > 259495b9dd31479d1913bed547e77bfedde5f38a4f810a0c79d66b9bd9510f62 > HSK[93558b8]: SERVER HELLO was send [74 bytes] > REC[93558b8]: Sending Packet[0] Handshake(22) with length: 74 > ASSERT: gnutls_cipher.c:204 > REC[93558b8]: Sent Packet[1] Handshake(22) with length: 79 > -------------------------------------- > > > --------------- Client --------------- > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA1 > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 > HSK[9bf1b58]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 > EXT[9bf1b58]: Sending extension CERT_TYPE > HSK[9bf1b58]: CLIENT HELLO was send [64 bytes] > REC[9bf1b58]: Sending Packet[0] Handshake(22) with length: 64 > ASSERT: gnutls_cipher.c:204 > WRITE: Will write 69 bytes to 4. > WRITE: wrote 69 bytes to 4. Left 0 bytes. Total 69 bytes. > 0000 - 16 03 02 00 40 01 00 00 3c 03 02 48 d2 00 41 bb > 0001 - 22 27 d1 ae 80 fd 96 1c e9 81 a2 bc c4 03 95 4b > 0002 - f9 10 2f 9a b7 c3 fe 5a e6 58 4a 00 00 0c 00 34 > 0003 - 00 46 00 3a 00 89 00 1b 00 18 01 00 00 07 00 09 > 0004 - 00 03 02 00 01 > REC[9bf1b58]: Sent Packet[1] Handshake(22) with length: 69 > READ: Got 5 bytes from 4 > READ: read 5 bytes from 4 > 0000 - 16 03 02 00 4a > RB: Have 0 bytes into buffer. Adding 5 bytes. > RB: Requested 5 bytes > REC[9bf1b58]: Expected Packet[0] Handshake(22) with length: 1 > REC[9bf1b58]: Received Packet[0] Handshake(22) with length: 74 > READ: Got 74 bytes from 4 > READ: read 74 bytes from 4 > 0000 - 02 00 00 46 03 02 48 d2 00 41 8e 8a 8d 30 de 33 > 0001 - 5f 2b f8 3f 93 bf 0e e8 5f 1a 68 ed f0 d6 82 1c > 0002 - cd d7 d9 97 8b 64 20 25 94 95 b9 dd 31 47 9d 19 > 0003 - 13 be d5 47 e7 7b fe dd e5 f3 8a 4f 81 0a 0c 79 > 0004 - d6 6b 9b d9 51 0f 62 00 34 00 > RB: Have 5 bytes into buffer. Adding 74 bytes. > RB: Requested 79 bytes > ASSERT: gnutls_cipher.c:204 > REC[9bf1b58]: Decrypted Packet[0] Handshake(22) with length: 74 > HSK[9bf1b58]: SERVER HELLO was received [74 bytes] > HSK[9bf1b58]: Server's version: 3.2 > HSK[9bf1b58]: SessionID length: 32 > HSK[9bf1b58]: SessionID > 259495b9dd31479d1913bed547e77bfedde5f38a4f810a0c79d66b9bd9510f62 > HSK[9bf1b58]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 > ASSERT: gnutls_extensions.c:125 > READ: Got 0 bytes from 4 > READ: read 0 bytes from 4 > 0000 - > ASSERT: gnutls_buffers.c:638 > ASSERT: gnutls_record.c:909 > ASSERT: gnutls_buffers.c:1150 > ASSERT: gnutls_handshake.c:1043 > ASSERT: gnutls_kx.c:410 > ASSERT: gnutls_handshake.c:2364 > -------------------------------------- > > As there seems to be handshaking conversation and the client starts the > conversation I don't know where to search for the error. Client and > server and both on the same machine, using the same GNUTLS library. > > Can anybody help me? I don't see anything wrong here, it looks like the server didn't send any extensions (0 bytes). Can you enable more debugging, e.g., log level 4711? If anyone else spots anything, please tell us. Btw, which version are you using? /Simon From lennart at scopeport.org Thu Sep 18 12:34:45 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Thu, 18 Sep 2008 12:34:45 +0200 Subject: [Help-gnutls] Re: Another one: A TLS packet with unexpected length was received. Message-ID: <1221734085.2856.18.camel@sundaysister> Thank you for your help! > Btw, which version are you using? I am using version 2.5.2. > Can you enable more debugging, e.g., log > level 4711? Here you are: --------------- Server --------------- READ: Got 5 bytes from 6 READ: read 5 bytes from 6 0000 - 16 03 02 00 40 RB: Have 0 bytes into buffer. Adding 5 bytes. RB: Requested 5 bytes REC[9e9a880]: Expected Packet[0] Handshake(22) with length: 1 REC[9e9a880]: Received Packet[0] Handshake(22) with length: 64 READ: Got 64 bytes from 6 READ: read 64 bytes from 6 0000 - 01 00 00 3c 03 02 48 d2 2c 91 72 a1 bb bf d8 6b 0001 - 3d df 9d 50 be a9 26 af ac 2c aa 93 48 83 db fb 0002 - 45 26 35 55 fd be 00 00 0c 00 34 00 46 00 3a 00 0003 - 89 00 1b 00 18 01 00 00 07 00 09 00 03 02 00 01 0004 - RB: Have 5 bytes into buffer. Adding 64 bytes. RB: Requested 69 bytes ASSERT: gnutls_cipher.c:204 REC[9e9a880]: Decrypted Packet[0] Handshake(22) with length: 64 BUF[HSK]: Inserted 64 bytes of Data(22) BUF[REC][HD]: Read 1 bytes of Data(22) BUF[REC][HD]: Read 3 bytes of Data(22) HSK[9e9a880]: CLIENT HELLO was received [64 bytes] BUF[REC][HD]: Read 60 bytes of Data(22) BUF[HSK]: Peeked 0 bytes of Data BUF[HSK]: Emptied buffer BUF[HSK]: Inserted 4 bytes of Data BUF[HSK]: Inserted 60 bytes of Data HSK[9e9a880]: Client's version: 3.2 ASSERT: gnutls_db.c:238 EXT[9e9a880]: Received extension 'CERT_TYPE/9' EXT[9e9a880]: Received extension 'CERT_TYPE/9' ASSERT: ext_cert_type.c:106 ASSERT: ext_cert_type.c:106 ASSERT: ext_cert_type.c:123 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA1 HSK[9e9a880]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 HSK[9e9a880]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 HSK[9e9a880]: Selected Compression Method: NULL HSK[9e9a880]: SessionID ce6b8f11699b491028039ed6c8cc58514ba2b62f627dafadc7e7554005f03eaf HSK[9e9a880]: SERVER HELLO was send [74 bytes] BUF[HSK]: Peeked 64 bytes of Data BUF[HSK]: Emptied buffer REC[9e9a880]: Sending Packet[0] Handshake(22) with length: 74 ASSERT: gnutls_cipher.c:204 WRITE: Will write 79 bytes to 6. WRITE: wrote 79 bytes to 6. Left 0 bytes. Total 79 bytes. 0000 - 16 03 02 00 4a 02 00 00 46 03 02 48 d2 2c 91 05 0001 - e5 a3 ea a3 f8 5c 23 98 c4 79 77 9c ff 75 7c 7d 0002 - 2a 3b be 6b a0 ea 0b 7a 51 5d 43 20 ce 6b 8f 11 0003 - 69 9b 49 10 28 03 9e d6 c8 cc 58 51 4b a2 b6 2f 0004 - 62 7d af ad c7 e7 55 40 05 f0 3e af 00 34 00 REC[9e9a880]: Sent Packet[1] Handshake(22) with length: 79 -------------------------------------- --------------- Client --------------- HSK[8452430]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1 HSK[8452430]: Keeping ciphersuite: ANON_DH_CAMELLIA_128_CBC_SHA1 HSK[8452430]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1 HSK[8452430]: Keeping ciphersuite: ANON_DH_CAMELLIA_256_CBC_SHA1 HSK[8452430]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 HSK[8452430]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5 EXT[8452430]: Sending extension CERT_TYPE HSK[8452430]: CLIENT HELLO was send [64 bytes] BUF[HSK]: Peeked 0 bytes of Data BUF[HSK]: Emptied buffer REC[8452430]: Sending Packet[0] Handshake(22) with length: 64 ASSERT: gnutls_cipher.c:204 WRITE: Will write 69 bytes to 4. WRITE: wrote 69 bytes to 4. Left 0 bytes. Total 69 bytes. 0000 - 16 03 02 00 40 01 00 00 3c 03 02 48 d2 2c 91 72 0001 - a1 bb bf d8 6b 3d df 9d 50 be a9 26 af ac 2c aa 0002 - 93 48 83 db fb 45 26 35 55 fd be 00 00 0c 00 34 0003 - 00 46 00 3a 00 89 00 1b 00 18 01 00 00 07 00 09 0004 - 00 03 02 00 01 REC[8452430]: Sent Packet[1] Handshake(22) with length: 69 READ: Got 5 bytes from 4 READ: read 5 bytes from 4 0000 - 16 03 02 00 4a RB: Have 0 bytes into buffer. Adding 5 bytes. RB: Requested 5 bytes REC[8452430]: Expected Packet[0] Handshake(22) with length: 1 REC[8452430]: Received Packet[0] Handshake(22) with length: 74 READ: Got 74 bytes from 4 READ: read 74 bytes from 4 0000 - 02 00 00 46 03 02 48 d2 2c 91 05 e5 a3 ea a3 f8 0001 - 5c 23 98 c4 79 77 9c ff 75 7c 7d 2a 3b be 6b a0 0002 - ea 0b 7a 51 5d 43 20 ce 6b 8f 11 69 9b 49 10 28 0003 - 03 9e d6 c8 cc 58 51 4b a2 b6 2f 62 7d af ad c7 0004 - e7 55 40 05 f0 3e af 00 34 00 RB: Have 5 bytes into buffer. Adding 74 bytes. RB: Requested 79 bytes ASSERT: gnutls_cipher.c:204 REC[8452430]: Decrypted Packet[0] Handshake(22) with length: 74 BUF[HSK]: Inserted 74 bytes of Data(22) BUF[REC][HD]: Read 1 bytes of Data(22) BUF[REC][HD]: Read 3 bytes of Data(22) HSK[8452430]: SERVER HELLO was received [74 bytes] BUF[REC][HD]: Read 70 bytes of Data(22) BUF[HSK]: Peeked 0 bytes of Data BUF[HSK]: Emptied buffer BUF[HSK]: Inserted 4 bytes of Data BUF[HSK]: Inserted 70 bytes of Data HSK[8452430]: Server's version: 3.2 HSK[8452430]: SessionID length: 32 HSK[8452430]: SessionID ce6b8f11699b491028039ed6c8cc58514ba2b62f627dafadc7e7554005f03eaf HSK[8452430]: Selected cipher suite: ANON_DH_AES_128_CBC_SHA1 ASSERT: gnutls_extensions.c:125 READ: Got 0 bytes from 4 READ: read 0 bytes from 4 0000 - ASSERT: gnutls_buffers.c:638 ASSERT: gnutls_record.c:909 ASSERT: gnutls_buffers.c:1150 ASSERT: gnutls_handshake.c:1043 ASSERT: gnutls_kx.c:410 ASSERT: gnutls_handshake.c:2364 BUF[HSK]: Cleared Data from buffer Handshake failed GNUTLS ERROR: A TLS packet with unexpected length was received. -------------------------------------- From beuc at beuc.net Fri Sep 19 13:52:20 2008 From: beuc at beuc.net (Sylvain Beucler) Date: Fri, 19 Sep 2008 13:52:20 +0200 Subject: [Help-gnutls] Multi-domain certificate request In-Reply-To: References: <20080913130912.GA19482@perso.beuc.net> <48CECE3A.2070407@gnutls.org> Message-ID: <20080919115220.GA20659@perso.beuc.net> [kicking the conversation] I would like to use 'subjectAltName' indeed. Is there a way to use it in GnuTLS? -- Sylvain On Tue, Sep 16, 2008 at 09:48:42AM +0530, Mahesh Nayak wrote: > Hye Nikos, > > But then we did have "subjectAltName" on GnuTLS (I used it long time back). > Cant this be used for multi domain DNS names? > > Cheers, > Mahesh > > On Tue, Sep 16, 2008 at 2:36 AM, Nikos Mavrogiannopoulos wrote: > > > Sylvain Beucler wrote: > > > Hi, > > > > > > I'd like to issue a certificate request for multiple domains / virtual > > > hosts, as described here: > > > http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly > > > > > > I didn't find how to do it using certtool. Is there something similar > > > to openssl's "subjectAltName"? > > > > > > I found a reference to "dns_name" but it only accepts a single value. > > > > As far as I remember the option to adding multiple dns names was never > > added to certtool so far. > > > > regards, > > Nikos From nmav at gnutls.org Fri Sep 19 21:16:46 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Sep 2008 22:16:46 +0300 Subject: [Help-gnutls] Multi-domain certificate request In-Reply-To: <20080919115220.GA20659@perso.beuc.net> References: <20080913130912.GA19482@perso.beuc.net> <48CECE3A.2070407@gnutls.org> <20080919115220.GA20659@perso.beuc.net> Message-ID: <48D3FA9E.4040409@gnutls.org> Sylvain Beucler wrote: > [kicking the conversation] > > I would like to use 'subjectAltName' indeed. > Is there a way to use it in GnuTLS? You cannot set multiple subjectAltNames currently with gnutls. regards, Nikos From nmav at gnutls.org Sat Sep 20 13:27:40 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Sep 2008 14:27:40 +0300 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. In-Reply-To: <1221725356.2856.9.camel@sundaysister> References: <1221725356.2856.9.camel@sundaysister> Message-ID: <48D4DE2C.3090809@gnutls.org> Lennart Koopmann wrote: > Hello everyone, > > i am currently implementing a handshaking procedure. Everything works > fine when the client chooses not to use TLS. But when TLS is requested, > the gnutls_handshake() fails. > > The client reports the following error: GNUTLS ERROR: A TLS packet with > unexpected length was received. > > The server reports no error, because gnutls_handshake() seems to wait > for something and just blocks. > > Here is some debug data (loglevel 7). > > --------------- Server --------------- > > As there seems to be handshaking conversation and the client starts the > conversation I don't know where to search for the error. Client and > server and both on the same machine, using the same GNUTLS library. There must be an error with your transport layer functions. Can you verify that the data actually arrive to gnutls functions? Do you see data on the network? regards, Nikos From nmav at gnutls.org Sat Sep 20 13:34:52 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Sep 2008 14:34:52 +0300 Subject: [Help-gnutls] Multi-domain certificate request In-Reply-To: <48D3FA9E.4040409@gnutls.org> References: <20080913130912.GA19482@perso.beuc.net> <48CECE3A.2070407@gnutls.org> <20080919115220.GA20659@perso.beuc.net> <48D3FA9E.4040409@gnutls.org> Message-ID: <48D4DFDC.9060209@gnutls.org> Nikos Mavrogiannopoulos wrote: > Sylvain Beucler wrote: >> [kicking the conversation] >> >> I would like to use 'subjectAltName' indeed. >> Is there a way to use it in GnuTLS? > > You cannot set multiple subjectAltNames currently with gnutls. and to modify my answer, this has been fixed in the development branch with this patch: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commit;h=4ed6efe3f9711b16fda407d90896ab67def7156d then you can specify multiple 'dns_name' or 'ip_addr' variables in the template file. regards, Nikos From lennart at scopeport.org Sat Sep 27 13:26:01 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Sat, 27 Sep 2008 13:26:01 +0200 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. In-Reply-To: <48D4DE2C.3090809@gnutls.org> References: <1221725356.2856.9.camel@sundaysister> <48D4DE2C.3090809@gnutls.org> Message-ID: <1222514762.6143.2.camel@sundaysister> Am Samstag, den 20.09.2008, 14:27 +0300 schrieb Nikos Mavrogiannopoulos: > There must be an error with your transport layer functions. Can you > verify that the data actually arrive to gnutls functions? Do you see > data on the network? Hey Nikos, sorry for the delay. I had a lot of work last week. Here is what I can see with wireshark: Client: SENSORSEND_GNUTLS Server: TLS-OK Client: STARTTLS Client: .... at ...<..H..j..K.t.......N..3...>.w'..(."....4.F.:................. Server: ....J...F..H...%....`"b-........2..x...).cV..2...(,...........x...u........4. This looks quite normal to me. There seems to be normal TLS conversation. Thank you. So long Lennart From lennart at scopeport.org Sat Sep 27 14:22:59 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Sat, 27 Sep 2008 14:22:59 +0200 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. In-Reply-To: References: <1221725356.2856.9.camel@sundaysister> <48D4DE2C.3090809@gnutls.org> <1222514762.6143.2.camel@sundaysister> Message-ID: <1222518179.6143.7.camel@sundaysister> Am Samstag, den 27.09.2008, 15:14 +0300 schrieb Nikos Mavrogiannopoulos: > I'd prefer to see the actual wireshark output. The output you attach > is not of any help to me. I attached a saved wireshark capture. It shows one cycle of packets the client is sending to the server. (A cycle like this is sent every 60 seconds) Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: conversation Type: application/octet-stream Size: 14963 bytes Desc: not available URL: From lennart at scopeport.org Sat Sep 27 16:15:33 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Sat, 27 Sep 2008 16:15:33 +0200 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. In-Reply-To: References: <1221725356.2856.9.camel@sundaysister> <48D4DE2C.3090809@gnutls.org> <1222514762.6143.2.camel@sundaysister> <1222518179.6143.7.camel@sundaysister> Message-ID: <1222524933.6143.20.camel@sundaysister> Am Samstag, den 27.09.2008, 16:16 +0300 schrieb Nikos Mavrogiannopoulos: > In the capture you sent me I cannot see a full TLS handshake. I can > see that the server sends a FIN after the server hello message and > thus terminates the TCP connection, so the behavior you see looks > normal. What do you think this FIN comes from? The server blocks at gnutls_handshake(), the client runs through it. So I think the FIN must come from the inside of gnutls_handshake(). I just saw that there is a RST at the end of the capture. I forgot to stop capturing before closing the server and client (what did of course close the sockets). But I think you already noticed that. Thanks for all your help. Did anybody else encounter such an behaviour before? From nmav at gnutls.org Sat Sep 27 19:44:57 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Sep 2008 20:44:57 +0300 Subject: [Help-gnutls] Another one: A TLS packet with unexpected length was received. In-Reply-To: <1222524933.6143.20.camel@sundaysister> References: <1221725356.2856.9.camel@sundaysister> <48D4DE2C.3090809@gnutls.org> <1222514762.6143.2.camel@sundaysister> <1222518179.6143.7.camel@sundaysister> <1222524933.6143.20.camel@sundaysister> Message-ID: <48DE7119.9090603@gnutls.org> Lennart Koopmann wrote: > Am Samstag, den 27.09.2008, 16:16 +0300 schrieb Nikos Mavrogiannopoulos: >> In the capture you sent me I cannot see a full TLS handshake. I can >> see that the server sends a FIN after the server hello message and >> thus terminates the TCP connection, so the behavior you see looks >> normal. > > What do you think this FIN comes from? It cannot be from gnutls. If you believe it is not please provide a small C program reproducing the problem. regards, Nikos From artu86yec at gmail.com Mon Sep 29 14:49:47 2008 From: artu86yec at gmail.com (Arturo Martinez Rubio) Date: Mon, 29 Sep 2008 15:49:47 +0300 Subject: [Help-gnutls] gnutls with unix domain (local) sockets Message-ID: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com> Hi everyone, Does anyone know if gnutls works over unix domain sockets? For example: sock = socket(PF_UNIX, SOCK_STREAM, 0); ... gnutls_transport_set_ptr(session, sock); ... Thanks, Arturo M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Sep 29 15:09:24 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Sep 2008 16:09:24 +0300 Subject: [Help-gnutls] gnutls with unix domain (local) sockets In-Reply-To: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com> References: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com> Message-ID: <48E0D384.1010401@gnutls.org> Arturo Martinez Rubio wrote: > Hi everyone, > > Does anyone know if gnutls works over unix domain sockets? > For example: > > sock = socket(PF_UNIX, SOCK_STREAM, 0); > ... > gnutls_transport_set_ptr(session, sock); > ... It does. What would be the benefit of such an operation though? From artu86yec at gmail.com Mon Sep 29 15:44:49 2008 From: artu86yec at gmail.com (Arturo Martinez Rubio) Date: Mon, 29 Sep 2008 16:44:49 +0300 Subject: [Help-gnutls] gnutls with unix domain (local) sockets In-Reply-To: <48E0D384.1010401@gnutls.org> References: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com> <48E0D384.1010401@gnutls.org> Message-ID: <7a9ca1180809290644q1164694nd706c6819de24d2d@mail.gmail.com> Well, basically the benefit is that UNIX sockets are supposed to have better performance that TCP sockets. In my specific case, the applications which will communicate using TLS are running in the same machine. Thanks for your answer, Arturo 2008/9/29 Nikos Mavrogiannopoulos > Arturo Martinez Rubio wrote: > > Hi everyone, > > > > Does anyone know if gnutls works over unix domain sockets? > > For example: > > > > sock = socket(PF_UNIX, SOCK_STREAM, 0); > > ... > > gnutls_transport_set_ptr(session, sock); > > ... > > It does. What would be the benefit of such an operation though? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart at scopeport.org Mon Sep 29 15:48:19 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Mon, 29 Sep 2008 15:48:19 +0200 Subject: [Help-gnutls] gnutls with unix domain (local) sockets In-Reply-To: <7a9ca1180809290644q1164694nd706c6819de24d2d@mail.gmail.com> References: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com> <48E0D384.1010401@gnutls.org> <7a9ca1180809290644q1164694nd706c6819de24d2d@mail.gmail.com> Message-ID: <1222696099.2874.15.camel@sundaysister> Am Montag, den 29.09.2008, 16:44 +0300 schrieb Arturo Martinez Rubio: > In my specific case, the applications which will communicate using TLS > are running in the same machine. Isn't TLS pretty useless if used for interprocess communication? Or does some kind of server that is running on the local machine require TLS?