From zkrebs at gmail.com Tue Feb 1 18:12:31 2011 From: zkrebs at gmail.com (Zachary Krebs) Date: Tue, 1 Feb 2011 09:12:31 -0800 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: References: Message-ID: I sent this to the libcurl community and they asked me to ping gnutls to see where the issue resides: Thanks for considering my support request, and I hope I do not agitate/irritate anyone by posting in the wrong place. I looked here first:?http://curl.haxx.se/mail/lib-2010-06/0169.html and did not find a resolution. I am attempting to use the Website Payment Pro Paypal module with Drupal CMS. My system is: Ubuntu 10.04 32-bit libcurl3-gnutls (7.18.0-1ubuntu2.2) libcurl 7.19.7 PHP 5.2.16 with Suhosin-Patch 0.9.7 (cli) (built: Dec 25 2010 19:12:01) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies Drupal 6 Nginx 0.9.3 When I attempt to complete a payment, I get an error in my log: "GnuTLS recv error (-9): A TLS packet with unexpected length was received" I searched all over Google, and another party stated "I will say this about the Paypal WPP service...I have been on it since it was available and find most (if not all) of our headache problems to be related to a dependency between some platform library and curl." Could someone point me in the right direction of getting this solved, perhaps I need to update a library or piece of software? https://bugs.launchpad.net/gwibber/+bug/626023/comments/28?was also suggested, "The only way i managed to get rid of that error, was by recompiling libcurl with OpenSSL instead of GnuTLS and then recompiling python-pycurl against the new cURL library." Can someone hold my hand through this? Thanks for your help, Zachary From nmav at gnutls.org Wed Feb 2 10:38:31 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 02 Feb 2011 10:38:31 +0100 Subject: breaking compatibility for 2.12.0 Message-ID: <4D492617.9080806@gnutls.org> Hello, It seems that with the changes occurred in 2.11.x breaking of backwards compatibility is required, i.e. removal of some functions. Those were exporting/depending on internal data, that are no longer there and it is not possible to emulate them. They are: gnutls_certificate_get_x509_crls gnutls_certificate_get_x509_cas I cannot find a way to avoid that, except making those function return NULL data, but this will harm any applications using those functions. Moreover I've deprecated already several other functions with bad interfaces, ones that depend on internal data, or replaced by "better" ones. All the deprecated functions are: gnutls_ext_register: DEPRECATED gnutls_session_get_server_random: DEPRECATED gnutls_session_get_client_random: DEPRECATED gnutls_session_get_master_secret: DEPRECATED gnutls_x509_crt_verify_hash: DEPRECATED (use: gnutls_pubkey_verify_hash) gnutls_x509_crt_verify_data: DEPRECATED (use: gnutls_pubkey_verify_data) gnutls_x509_crt_get_verify_algorithm: DEPRECATED (use: gnutls_pubkey_get_verify_algorithm) gnutls_x509_crt_get_preferred_hash_algorithm: DEPRECATED (use: gnutls_pubkey_get_preferred_hash_algorithm) gnutls_openpgp_privkey_sign_hash: DEPRECATED (use: gnutls_privkey_sign_hash2) gnutls_x509_crq_sign2: DEPRECATED (use: gnutls_x509_crq_privkey_sign) gnutls_x509_crq_sign: DEPRECATED (use: gnutls_x509_crq_privkey_sign) gnutls_x509_crq_get_preferred_hash_algorithm: DEPRECATED gnutls_x509_crl_sign: DEPRECATED (use: gnutls_x509_crl_privkey_sign) gnutls_x509_crl_sign2: DEPRECATED (use: gnutls_x509_crl_privkey_sign) gnutls_x509_privkey_sign_data: DEPRECATED (use: gnutls_privkey_sign_data2) gnutls_x509_privkey_sign_hash: DEPRECATED (use: gnutls_privkey_sign_hash2) gnutls_x509_privkey_verify_data: DEPRECATED (use: gnutls_pubkey_verify_data) gnutls_psk_netconf_derive_key: DEPRECATED gnutls_session_set_finished_function: DEPRECATED regards, Nikos From nmav at gnutls.org Wed Feb 2 08:09:38 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 02 Feb 2011 08:09:38 +0100 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: References: Message-ID: <4D490332.3000201@gnutls.org> On 02/01/2011 06:12 PM, Zachary Krebs wrote: > I sent this to the libcurl community and they asked me to ping gnutls > to see where the issue resides: > > Thanks for considering my support request, and I hope I do not > agitate/irritate anyone by posting in the wrong place. > I looked here first: http://curl.haxx.se/mail/lib-2010-06/0169.html > and did not find a resolution. > I am attempting to use the Website Payment Pro Paypal module with Drupal CMS. [...] > When I attempt to complete a payment, I get an error in my log: > "GnuTLS recv error (-9): A TLS packet with unexpected length was received" Several sites terminate the TLS connection without following the TLS protocol (i.e. sending closure alerts), but rather terminate the TCP connection directly. This is a relic of SSLv2 and it seems other implementations ignore this error. GnuTLS doesn't and thus prints this error. You could ignore it, but then you could not distinguish between a premature connection termination (i.e. by someone injecting a stray TCP termination packet) and normal termination. regards, Nikos From zkrebs at gmail.com Wed Feb 2 20:07:20 2011 From: zkrebs at gmail.com (Zachary Krebs) Date: Wed, 2 Feb 2011 11:07:20 -0800 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: <4D490332.3000201@gnutls.org> References: <4D490332.3000201@gnutls.org> Message-ID: Nikos, Do you have a suggestion for me - is it related to an issue with GnuTLS or Libcurl? If no, then is it a library on Ubuntu 10.04? Or is it a flaw in the software I'm using? Drupal / Ubercart / Ubercart Payment Gateway for Paypal Website Payment Pro? This feels like a needle in the haystack for me. On Tue, Feb 1, 2011 at 11:09 PM, Nikos Mavrogiannopoulos wrote: > On 02/01/2011 06:12 PM, Zachary Krebs wrote: >> I sent this to the libcurl community and they asked me to ping gnutls >> to see where the issue resides: >> >> Thanks for considering my support request, and I hope I do not >> agitate/irritate anyone by posting in the wrong place. >> I looked here first: http://curl.haxx.se/mail/lib-2010-06/0169.html >> and did not find a resolution. >> I am attempting to use the Website Payment Pro Paypal module with Drupal CMS. > [...] >> When I attempt to complete a payment, I get an error in my log: >> "GnuTLS recv error (-9): A TLS packet with unexpected length was received" > > Several sites terminate the TLS connection without following the TLS > protocol (i.e. sending closure alerts), but rather terminate the TCP > connection directly. This is a relic of SSLv2 and it seems other > implementations ignore this error. GnuTLS doesn't and thus prints > this error. You could ignore it, but then you could not distinguish > between a premature connection termination (i.e. by someone injecting > a stray TCP termination packet) and normal termination. > > regards, > Nikos > From joe at manyfish.co.uk Wed Feb 2 23:33:50 2011 From: joe at manyfish.co.uk (Joe Orton) Date: Wed, 2 Feb 2011 22:33:50 +0000 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: <4D490332.3000201@gnutls.org> References: <4D490332.3000201@gnutls.org> Message-ID: <20110202223349.GA5981@manyfish.co.uk> On Wed, Feb 02, 2011 at 08:09:38AM +0100, Nikos Mavrogiannopoulos wrote: > On 02/01/2011 06:12 PM, Zachary Krebs wrote: > > I sent this to the libcurl community and they asked me to ping gnutls > > to see where the issue resides: > > > > Thanks for considering my support request, and I hope I do not > > agitate/irritate anyone by posting in the wrong place. > > I looked here first: http://curl.haxx.se/mail/lib-2010-06/0169.html > > and did not find a resolution. > > I am attempting to use the Website Payment Pro Paypal module with Drupal CMS. > [...] > > When I attempt to complete a payment, I get an error in my log: > > "GnuTLS recv error (-9): A TLS packet with unexpected length was received" > > Several sites terminate the TLS connection without following the TLS > protocol (i.e. sending closure alerts), but rather terminate the TCP > connection directly. This is a relic of SSLv2 and it seems other > implementations ignore this error. GnuTLS doesn't and thus prints > this error. You could ignore it, but then you could not distinguish > between a premature connection termination (i.e. by someone injecting > a stray TCP termination packet) and normal termination. The problem is that GnuTLS does not distinguish the TCP closure case from this rather generic "unexpected length" error, as has been discussed on this list before. The OpenSSL API does expose this distinction. It is not uncommon for SSL servers to perform unclean TCP closure in some cases and HTTP clients can safely work around it if the connection is in the right state. Zachary, if you disable keepalive support in libcurl, does it work? Regards, Joe From nmav at gnutls.org Thu Feb 3 11:03:10 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 3 Feb 2011 11:03:10 +0100 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: <20110202223349.GA5981@manyfish.co.uk> References: <4D490332.3000201@gnutls.org> <20110202223349.GA5981@manyfish.co.uk> Message-ID: On Wed, Feb 2, 2011 at 11:33 PM, Joe Orton wrote: >> Several sites terminate the TLS connection without following the TLS >> protocol (i.e. sending closure alerts), but rather terminate the TCP >> connection directly. This is a relic of SSLv2 and it seems other >> implementations ignore this error. GnuTLS doesn't and thus prints >> this error. You could ignore it, but then you could not distinguish >> between a premature connection termination (i.e. by someone injecting >> a stray TCP termination packet) and normal termination. > The problem is that GnuTLS does not distinguish the TCP closure case > from this rather generic "unexpected length" error, as has been > discussed on this list before. ?The OpenSSL API does expose this > distinction. How does openssl expose this distinction? Does it have a separate error for unclean termination? regards, Nikos From joe at manyfish.co.uk Thu Feb 3 13:14:17 2011 From: joe at manyfish.co.uk (Joe Orton) Date: Thu, 3 Feb 2011 12:14:17 +0000 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: References: <4D490332.3000201@gnutls.org> <20110202223349.GA5981@manyfish.co.uk> Message-ID: <20110203121417.GA12195@manyfish.co.uk> On Thu, Feb 03, 2011 at 11:03:10AM +0100, Nikos Mavrogiannopoulos wrote: > On Wed, Feb 2, 2011 at 11:33 PM, Joe Orton wrote: > >> Several sites terminate the TLS connection without following the TLS > >> protocol (i.e. sending closure alerts), but rather terminate the TCP > >> connection directly. This is a relic of SSLv2 and it seems other > >> implementations ignore this error. GnuTLS doesn't and thus prints > >> this error. You could ignore it, but then you could not distinguish > >> between a premature connection termination (i.e. by someone injecting > >> a stray TCP termination packet) and normal termination. > > The problem is that GnuTLS does not distinguish the TCP closure case > > from this rather generic "unexpected length" error, as has been > > discussed on this list before. ?The OpenSSL API does expose this > > distinction. > > How does openssl expose this distinction? Does it have a separate error for > unclean termination? Via the SSL_get_error() interface, see part on SSL_ERROR_SYSCALL. Regards, Joe From nmav at gnutls.org Thu Feb 3 13:21:59 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 3 Feb 2011 13:21:59 +0100 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: <20110203121417.GA12195@manyfish.co.uk> References: <4D490332.3000201@gnutls.org> <20110202223349.GA5981@manyfish.co.uk> <20110203121417.GA12195@manyfish.co.uk> Message-ID: On Thu, Feb 3, 2011 at 1:14 PM, Joe Orton wrote: >> > The problem is that GnuTLS does not distinguish the TCP closure case >> > from this rather generic "unexpected length" error, as has been >> > discussed on this list before. ?The OpenSSL API does expose this >> > distinction. >> How does openssl expose this distinction? Does it have a separate error for >> unclean termination? > Via the SSL_get_error() interface, see part on SSL_ERROR_SYSCALL. Marking it a syscall error doesn't really point the fact of premature termination. Would having a special error code on this issue, such as GNUTLS_E_PREMATURE_TERMINATION make things better for applications? regards, Nikos PS. To Zachary... A suggestion would be to ignore that error. From danw at gnome.org Thu Feb 3 14:40:21 2011 From: danw at gnome.org (Dan Winship) Date: Thu, 03 Feb 2011 08:40:21 -0500 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: References: <4D490332.3000201@gnutls.org> <20110202223349.GA5981@manyfish.co.uk> <20110203121417.GA12195@manyfish.co.uk> Message-ID: <4D4AB045.1040205@gnome.org> On 02/03/2011 07:21 AM, Nikos Mavrogiannopoulos wrote: > Would having a special error code on this issue, such as > GNUTLS_E_PREMATURE_TERMINATION > make things better for applications? Yes, although that should be part of the ABI break you were talking about so it doesn't break people who expect to see GNUTLS_E_UNEXPECTED_PACKET_LENGTH for that now. Another case that currently gets "unexpected packet length" is if you try to handshake with a peer that's not actually speaking TLS. It seems like it wouldn't be hard for gnutls to notice that and return "GNUTLS_E_NOT_TLS" or something in that case. (It only needs to do it for the first packet received on the first handshake attempt.) This would let things like "gnutls-cli -p 80 www.gnutls.org" (and equivalent higher-level actions) fail with a better error message. > PS. To Zachary... A suggestion would be to ignore that error. Or, if you're using push/pull funcs, you can have the pull func set a flag when it gets an EOF, and then later if you get GNUTLS_E_UNEXPECTED_PACKET_LENGTH, check if you'd gotten an EOF. Then that at least distinguishes "connection terminated prematurely" from "the server suddenly started speaking gibberish". -- Dan From wk at gnupg.org Thu Feb 3 15:54:25 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Feb 2011 15:54:25 +0100 Subject: breaking compatibility for 2.12.0 In-Reply-To: <4D492617.9080806@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 02 Feb 2011 10:38:31 +0100") References: <4D492617.9080806@gnutls.org> Message-ID: <878vxxjhi6.fsf@vigenere.g10code.de> On Wed, 2 Feb 2011 10:38, nmav at gnutls.org said: > It seems that with the changes occurred in 2.11.x breaking > of backwards compatibility is required, i.e. removal of some > functions. Those were exporting/depending on internal data, that If you really want to break ABI compatibility, please make that clear to the users by bumping the version number (e.g. to 3). Only changing the SO name is technically okay but it comes as a surprise. Please also consider that GnuTLS is used by too many projects to allow for an easy API break. A better strategy is to warn the user for a few years that those functions will eventually be removed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vincent.torri at gmail.com Fri Feb 4 06:10:31 2011 From: vincent.torri at gmail.com (Vincent Torri) Date: Fri, 4 Feb 2011 06:10:31 +0100 Subject: wrong gnutls.pc In-Reply-To: <20100316190246.GA3816@downhill.g.la> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> <87aau9xw8y.fsf@mocca.josefsson.org> <20100316190246.GA3816@downhill.g.la> Message-ID: Hey, On Tue, Mar 16, 2010 at 8:02 PM, Andreas Metzler < ametzler at downhill.at.eu.org> wrote: > On 2010-03-15 Simon Josefsson wrote: > > Andreas Metzler writes: > > > On 2010-02-28 Andreas Metzler wrote: > > > [...] > > >> Patches against git head attached. This should also go to the 2.8.x > > >> series. > > > > Saved as http://savannah.gnu.org/support/?107310 > > > Oops, I missed that for 2.8.6. Is the patch in savannah still the best > > version? I think we could apply it easily soon. > [...] > > Hello, > I have not got an update, and there has not been any change in GIT > that requires changes to the patches, afaict. The whole > "GNUTLS_REQUIRES_PRIVATE" macro is less than elegant, though. ;-) > What about the status of that bug report ? Afaics, this has not been fixed in the last release thanks Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.torri at gmail.com Fri Feb 4 06:13:29 2011 From: vincent.torri at gmail.com (Vincent Torri) Date: Fri, 4 Feb 2011 06:13:29 +0100 Subject: from openldap ML: GnuTLS considered harmful Message-ID: Hey, a guy on the libcurl ML mentioned that mail on openldap ML: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html The mail is a bit old (2008). What is the status of that problem ? thank you Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Feb 4 12:17:20 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Feb 2011 12:17:20 +0100 Subject: from openldap ML: GnuTLS considered harmful In-Reply-To: References: Message-ID: On Fri, Feb 4, 2011 at 6:13 AM, Vincent Torri wrote: > Hey, > ?a guy on the libcurl ML mentioned that mail on openldap ML: > http://www.openldap.org/lists/openldap-devel/200802/msg00072.html > The mail is a bit old (2008). What is the status of that problem ? It has been discussed before. We don't cosider it a problem. http://old.nabble.com/GnuTLS-considered-harmful-td28718812.html regards, Nikos From vincent.torri at gmail.com Fri Feb 4 12:19:32 2011 From: vincent.torri at gmail.com (Vincent Torri) Date: Fri, 4 Feb 2011 12:19:32 +0100 Subject: from openldap ML: GnuTLS considered harmful In-Reply-To: References: Message-ID: On Fri, Feb 4, 2011 at 12:17 PM, Nikos Mavrogiannopoulos wrote: > On Fri, Feb 4, 2011 at 6:13 AM, Vincent Torri > wrote: > > Hey, > > a guy on the libcurl ML mentioned that mail on openldap ML: > > http://www.openldap.org/lists/openldap-devel/200802/msg00072.html > > The mail is a bit old (2008). What is the status of that problem ? > > It has been discussed before. We don't cosider it a problem. > http://old.nabble.com/GnuTLS-considered-harmful-td28718812.html > good to know :-) Thank you Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sat Feb 5 10:26:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Feb 2011 10:26:12 +0100 Subject: wrong gnutls.pc In-Reply-To: References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> <87aau9xw8y.fsf@mocca.josefsson.org> <20100316190246.GA3816@downhill.g.la> Message-ID: <4D4D17B4.9000105@gnutls.org> On 02/04/2011 06:10 AM, Vincent Torri wrote: > Hey, >> On 2010-03-15 Simon Josefsson wrote: >>> Andreas Metzler writes: >>>> On 2010-02-28 Andreas Metzler wrote: >>>> [...] >>>>> Patches against git head attached. This should also go to the 2.8.x >>>>> series. >> >>>> Saved as http://savannah.gnu.org/support/?107310 >> >>> Oops, I missed that for 2.8.6. Is the patch in savannah still the best >>> version? I think we could apply it easily soon. >> [...] >> >> Hello, >> I have not got an update, and there has not been any change in GIT >> that requires changes to the patches, afaict. The whole >> "GNUTLS_REQUIRES_PRIVATE" macro is less than elegant, though. ;-) > What about the status of that bug report ? Afaics, this has not been fixed > in the last release I've just applied the patch in the git master and 2.10.x branch. I have to figure out how it can work with libnettle though... anyways applied. Thank you for the reminder and Andreas for the patches. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Feb 5 10:31:26 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Feb 2011 09:31:26 +0000 Subject: [sr #107310] incomplete *.private in pkg-config files In-Reply-To: <20100315-185234.sv20807.672@savannah.gnu.org> References: <20100315-185234.sv20807.672@savannah.gnu.org> Message-ID: <20110205-113126.sv707.6448@savannah.gnu.org> Update of sr #107310 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sat Feb 5 12:33:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Feb 2011 12:33:12 +0100 Subject: breaking compatibility for 2.12.0 In-Reply-To: <878vxxjhi6.fsf@vigenere.g10code.de> References: <4D492617.9080806@gnutls.org> <878vxxjhi6.fsf@vigenere.g10code.de> Message-ID: <4D4D3578.7040208@gnutls.org> On 02/03/2011 03:54 PM, Werner Koch wrote: > On Wed, 2 Feb 2011 10:38, nmav at gnutls.org said: > >> It seems that with the changes occurred in 2.11.x breaking of >> backwards compatibility is required, i.e. removal of some >> functions. Those were exporting/depending on internal data, that > If you really want to break ABI compatibility, please make that clear > to the users by bumping the version number (e.g. to 3). Only > changing the SO name is technically okay but it comes as a surprise. Indeed. We'll think about it. > Please also consider that GnuTLS is used by too many projects to > allow for an easy API break. A better strategy is to warn the user > for a few years that those functions will eventually be removed. The problem is that the discussed functions cannot be supported any more, and were not actually widely used. For the commonly used functions we mark them as deprecated and leave a compatibility layer. regards, Nikos From wk at gnupg.org Mon Feb 7 09:20:10 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Feb 2011 09:20:10 +0100 Subject: breaking compatibility for 2.12.0 In-Reply-To: <4D4D3578.7040208@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 05 Feb 2011 12:33:12 +0100") References: <4D492617.9080806@gnutls.org> <878vxxjhi6.fsf@vigenere.g10code.de> <4D4D3578.7040208@gnutls.org> Message-ID: <87ipwwcl39.fsf@vigenere.g10code.de> On Sat, 5 Feb 2011 12:33, nmav at gnutls.org said: > The problem is that the discussed functions cannot be supported any > more, and were not actually widely used. For the commonly used functions How do you know that? Checking the Debian packets gives only a first clue. But there are many more applications out there. Often these are in-house applications and the maintainers won't tell you about it. However they use gnutls as a stable and reliable library and trust that the gnutls maintainers handle ABI breaks with due diligance. That is to change the SO name and announce a reasonable EOL for the old ABI version. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tmraz at redhat.com Mon Feb 7 09:54:00 2011 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 07 Feb 2011 09:54:00 +0100 Subject: breaking compatibility for 2.12.0 In-Reply-To: <87ipwwcl39.fsf@vigenere.g10code.de> References: <4D492617.9080806@gnutls.org> <878vxxjhi6.fsf@vigenere.g10code.de> <4D4D3578.7040208@gnutls.org> <87ipwwcl39.fsf@vigenere.g10code.de> Message-ID: <1297068840.13324.7.camel@vespa.frost.loc> On Mon, 2011-02-07 at 09:20 +0100, Werner Koch wrote: > On Sat, 5 Feb 2011 12:33, nmav at gnutls.org said: > > > The problem is that the discussed functions cannot be supported any > > more, and were not actually widely used. For the commonly used functions > > How do you know that? Checking the Debian packets gives only a first > clue. But there are many more applications out there. Often these are > in-house applications and the maintainers won't tell you about it. > However they use gnutls as a stable and reliable library and trust that > the gnutls maintainers handle ABI breaks with due diligance. That is to > change the SO name and announce a reasonable EOL for the old ABI > version. I think the proper response here is to maintain the 2.10.x branch for a slightly longer time than usual perhaps even after the next branching event. Changing the SONAME in the new branch is of course a must. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From simon at josefsson.org Mon Feb 7 10:50:08 2011 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Feb 2011 10:50:08 +0100 Subject: TLS Inner Application? Message-ID: <87aai89nsf.fsf@latte.josefsson.org> Is anyone using or cares about TLS/IA support in GnuTLS? The implementation of TLS/IA was done against a draft that has expired 5 years ago and that never made it into a proper RFC. It would be nice to remove obsolete stuff, so we want to remove it. /Simon From nmav at gnutls.org Mon Feb 7 11:08:40 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Feb 2011 11:08:40 +0100 Subject: TLS Inner Application? In-Reply-To: <87aai89nsf.fsf@latte.josefsson.org> References: <87aai89nsf.fsf@latte.josefsson.org> Message-ID: <4D4FC4A8.5070408@gnutls.org> On 02/07/2011 10:50 AM, Simon Josefsson wrote: > Is anyone using or cares about TLS/IA support in GnuTLS? The > implementation of TLS/IA was done against a draft that has expired 5 > years ago and that never made it into a proper RFC. It would be > nice to remove obsolete stuff, so we want to remove it. Just to summarize our discussion in fosdem in list. The 2.12.x release will be a backwards compatible release with several "old" functions marked as deprecated. New functionality that breaks binary compatibility will wait for 3.0.0, where all obsolete functions will be removed. regards, Nikos From nmav at gnutls.org Mon Feb 7 17:12:30 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Feb 2011 17:12:30 +0100 Subject: GnuTLS recv error (-9): A TLS packet with unexpected length was received. - with Paypal Website Payment Pro In-Reply-To: <4D4AB045.1040205@gnome.org> References: <4D490332.3000201@gnutls.org> <20110202223349.GA5981@manyfish.co.uk> <20110203121417.GA12195@manyfish.co.uk> <4D4AB045.1040205@gnome.org> Message-ID: <4D5019EE.90607@gnutls.org> On 02/03/2011 02:40 PM, Dan Winship wrote: > On 02/03/2011 07:21 AM, Nikos Mavrogiannopoulos wrote: >> Would having a special error code on this issue, such as >> GNUTLS_E_PREMATURE_TERMINATION make things better for >> applications? > Yes, although that should be part of the ABI break you were talking > about so it doesn't break people who expect to see > GNUTLS_E_UNEXPECTED_PACKET_LENGTH for that now. The master branch (what will become 3.0.0), now distinguishes the EOF error from other parsing errors. > Another case that currently gets "unexpected packet length" is if > you try to handshake with a peer that's not actually speaking TLS. It > seems like it wouldn't be hard for gnutls to notice that and return > "GNUTLS_E_NOT_TLS" or something in that case. (It only needs to do > it for the first packet received on the first handshake attempt.) > This would let things like "gnutls-cli -p 80 www.gnutls.org" (and > equivalent higher-level actions) fail with a better error message. Actually this uncovered an error message that was not returned. The error should have been GNUTLS_E_UNEXPECTED_PACKET. gnutls cannot possibly distinguish between TLS and non-TLS data. It expects TLS data and if they are not given it will return the parsing error occurred. It is up to you to make the deduction that this is actually non-TLS. regards, Nikos From jkmalinen at gmail.com Tue Feb 8 17:47:57 2011 From: jkmalinen at gmail.com (Jouni Malinen) Date: Tue, 8 Feb 2011 18:47:57 +0200 Subject: TLS Inner Application? In-Reply-To: <87aai89nsf.fsf@latte.josefsson.org> References: <87aai89nsf.fsf@latte.josefsson.org> Message-ID: On Mon, Feb 7, 2011 at 11:50 AM, Simon Josefsson wrote: > Is anyone using or cares about TLS/IA support in GnuTLS? ?The > implementation of TLS/IA was done against a draft that has expired 5 > years ago and that never made it into a proper RFC. ?It would be nice to > remove obsolete stuff, so we want to remove it. There is a preliminary implementation of EAP-TTLSv1 in wpa_supplicant(peer) and hostapd(server). However, I do not know whether anyone really uses that, but there is indeed code that is currently assuming this functionality to be available in GnuTLS. That code is disabled by default in wpa_supplicant/hostapd, so removing this from GnuTLS would not break the default build. In addition, enabling of this code is not documented anywhere, so one would need to go through the source code to figure out how to enable this. - Jouni From simon at josefsson.org Tue Feb 8 18:51:05 2011 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Feb 2011 18:51:05 +0100 Subject: TLS Inner Application? In-Reply-To: (Jouni Malinen's message of "Tue, 8 Feb 2011 18:47:57 +0200") References: <87aai89nsf.fsf@latte.josefsson.org> Message-ID: <87lj1ql8ja.fsf@latte.josefsson.org> Jouni Malinen writes: > On Mon, Feb 7, 2011 at 11:50 AM, Simon Josefsson wrote: >> Is anyone using or cares about TLS/IA support in GnuTLS? ?The >> implementation of TLS/IA was done against a draft that has expired 5 >> years ago and that never made it into a proper RFC. ?It would be nice to >> remove obsolete stuff, so we want to remove it. > > There is a preliminary implementation of EAP-TTLSv1 in > wpa_supplicant(peer) and hostapd(server). However, I do not know > whether anyone really uses that, but there is indeed code that is > currently assuming this functionality to be available in GnuTLS. That > code is disabled by default in wpa_supplicant/hostapd, so removing > this from GnuTLS would not break the default build. In addition, > enabling of this code is not documented anywhere, so one would need to > go through the source code to figure out how to enable this. Thanks for information. Do you know if you managed to do interop of TLS/IA with anyone else? I'm wondering if there is still some people interested in the draft version of TLS/IA. /Simon From jkmalinen at gmail.com Wed Feb 9 10:32:13 2011 From: jkmalinen at gmail.com (Jouni Malinen) Date: Wed, 9 Feb 2011 11:32:13 +0200 Subject: TLS Inner Application? In-Reply-To: <87lj1ql8ja.fsf@latte.josefsson.org> References: <87aai89nsf.fsf@latte.josefsson.org> <87lj1ql8ja.fsf@latte.josefsson.org> Message-ID: On Tue, Feb 8, 2011 at 7:51 PM, Simon Josefsson wrote: > Thanks for information. ?Do you know if you managed to do interop of > TLS/IA with anyone else? ?I'm wondering if there is still some people > interested in the draft version of TLS/IA. I'm not aware of any other implementation of EAP-TTLSv1. I think I would like to see where IETF emu working group goes with the tunnel-based method development this year since at least in theory, EAP-TTLSv1 would be a possible submission into that process. However, once that is done and assuming EAP-TTLSv1 was not selected as a basis for it, there may be quite a bit less interest in TLS/IA in the future from EAP view point. - Jouni From nmav at gnutls.org Wed Feb 9 12:28:18 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 9 Feb 2011 12:28:18 +0100 Subject: TLS Inner Application? In-Reply-To: References: <87aai89nsf.fsf@latte.josefsson.org> <87lj1ql8ja.fsf@latte.josefsson.org> Message-ID: On Wed, Feb 9, 2011 at 10:32 AM, Jouni Malinen wrote: > On Tue, Feb 8, 2011 at 7:51 PM, Simon Josefsson wrote: >> Thanks for information. ?Do you know if you managed to do interop of >> TLS/IA with anyone else? ?I'm wondering if there is still some people >> interested in the draft version of TLS/IA. > I'm not aware of any other implementation of EAP-TTLSv1. > I think I would like to see where IETF emu working group goes with the > tunnel-based method development this year since at least in theory, > EAP-TTLSv1 would be a possible submission into that process. However, > once that is done and assuming EAP-TTLSv1 was not selected as a basis > for it, there may be quite a bit less interest in TLS/IA in the future > from EAP view point. Currently I have removed the TLS/IA implementation from what is to become 3.0.0 release, on the basis that the protocol itself is not published (and there is no indication that somebody plans to do it). Would submitting EAP-TTLSv1 to that process mean that somebody would revive the TLS/IA draft, or could they even modifying the method completely to avoid TLS/IA? (is there anyone to contact about that?) In any case the version to be released (2.12.x) will have this functionality available but marked as deprecated. If the protocol revives I'll add the functionality back to the development branch as well. regards, Nikos From jkmalinen at gmail.com Wed Feb 9 15:57:18 2011 From: jkmalinen at gmail.com (Jouni Malinen) Date: Wed, 9 Feb 2011 16:57:18 +0200 Subject: TLS Inner Application? In-Reply-To: References: <87aai89nsf.fsf@latte.josefsson.org> <87lj1ql8ja.fsf@latte.josefsson.org> Message-ID: On Wed, Feb 9, 2011 at 1:28 PM, Nikos Mavrogiannopoulos wrote: > Currently I have removed the TLS/IA implementation from what is to become > 3.0.0 release, on the basis that the protocol itself is not published (and there > is no indication that somebody plans to do it). Would submitting EAP-TTLSv1 > to that process mean that somebody would revive the TLS/IA draft, or could > they even modifying the method completely to avoid TLS/IA? > (is there anyone to contact about that?) If someone were to want to push for EAP-TTLSv1 to be used, then yes, TLS/IA would probably need to be revived, too. Both of these internet drafts expired years ago and I have not heard of much activity behind them since then. The design could be changed completely, too, but I'm not sure whether TTLSv1 would be the best starting point if that is the goal. Anyway, I would hope that we will know quite a bit more later this year. The IETF emu working group is the most likely place where activity on this area would happen. > In any case the version to be released (2.12.x) will have this functionality > available but marked as deprecated. If the protocol revives I'll add the > functionality back to the development branch as well. OK. I will probably remove the preliminary EAP-TTLSv1 implementation from hostapd/wpa_supplicant later this year once the emu process gets a bit further (obviously assuming that it does not move towards TTLSv1). - Jouni From etemper at walla.com Wed Feb 9 19:04:31 2011 From: etemper at walla.com (=?UTF-8?Q?=45=72=61=6E=20=54=65=6D=70=65=72?=) Date: Wed, 9 Feb 2011 20:04:31 +0200 Subject: Errors in the handshake process Message-ID: <1297274671.136000-76846783-9189@walla.com> An HTML attachment was scrubbed... URL: From simon at josefsson.org Wed Feb 9 19:55:38 2011 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 09 Feb 2011 19:55:38 +0100 Subject: TLS Inner Application? In-Reply-To: (Jouni Malinen's message of "Wed, 9 Feb 2011 16:57:18 +0200") References: <87aai89nsf.fsf@latte.josefsson.org> <87lj1ql8ja.fsf@latte.josefsson.org> Message-ID: <87wrl9xck5.fsf@latte.josefsson.org> Jouni Malinen writes: > On Wed, Feb 9, 2011 at 1:28 PM, Nikos Mavrogiannopoulos wrote: >> Currently I have removed the TLS/IA implementation from what is to become >> 3.0.0 release, on the basis that the protocol itself is not published (and there >> is no indication that somebody plans to do it). Would submitting EAP-TTLSv1 >> to that process mean that somebody would revive the TLS/IA draft, or could >> they even modifying the method completely to avoid TLS/IA? >> (is there anyone to contact about that?) > > If someone were to want to push for EAP-TTLSv1 to be used, then yes, > TLS/IA would probably need to be revived, too. Both of these internet > drafts expired years ago and I have not heard of much activity behind > them since then. The design could be changed completely, too, but I'm > not sure whether TTLSv1 would be the best starting point if that is > the goal. Anyway, I would hope that we will know quite a bit more > later this year. The IETF emu working group is the most likely place > where activity on this area would happen. > >> In any case the version to be released (2.12.x) will have this functionality >> available but marked as deprecated. If the protocol revives I'll add the >> functionality back to the development branch as well. > > OK. I will probably remove the preliminary EAP-TTLSv1 implementation > from hostapd/wpa_supplicant later this year once the emu process gets > a bit further (obviously assuming that it does not move towards > TTLSv1). Thanks for update -- based on this I think we are right to remove the implementation for GnuTLS 3.0. TLS/IA will still be available on older releases (and even in the next stable release) and if there is ever more interest in it, I'm sure we can revive the patches. It sounds as if TLS/IA is not going to look the same if it ever reaches RFC status. /Simon From simon at josefsson.org Wed Feb 9 20:57:24 2011 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 09 Feb 2011 20:57:24 +0100 Subject: TLS code size on OpenWRT 10.03 Message-ID: <87pqr1x9p7.fsf@latte.josefsson.org> Folks, For curiousity I built all TLS implementations that OpenWRT 10.03 supports, for the mips/brcm-2.4 platform (the default) like this: svn co svn://svn.openwrt.org/openwrt/branches/backfire mv backfire/ openwrt-10.03 cd openwrt-10.03/ make package/symlinks make menuconfig # go to Libraries=>SSL and enable them all make The installed (stripped) object size is as follows: jas at latte:~/src/openwrt-10.03$ ls -laR build_dir/target-mipsel_uClibc-0.9.30.1/*/ipkg-brcm-2.4|egrep -e '(libaxtls|libcyassl|libgnutls|libmatrixssl|libssl|libpolarssl)\.so' | grep -v -e ' -> ' -e \\.la -rwxr-xr-x 1 jas jas 74970 9 feb 20.06 libaxtls.so.1.2 -rwxr-xr-x 1 jas jas 144407 9 feb 20.04 libcyassl.so.0.0.0 -rwxr-xr-x 1 jas jas 548215 9 feb 20.10 libgnutls.so.26.14.12 -rwxr-xr-x 1 jas jas 82311 9 feb 20.10 libmatrixssl.so.1.2.4 -rw-r--r-- 1 jas jas 249115 9 feb 20.13 libssl.so.0.9.8 -rwxr-xr-x 1 jas jas 211210 9 feb 20.10 libpolarssl.so jas at latte:~/src/openwrt-10.03$ Of course, that isn't the complete picture since dependencies aren't included. I believe these dependencies are involved: -rwxr-xr-x 1 jas jas 66018 9 feb 20.06 libz.so.1.2.3 -rwxr-xr-x 1 jas jas 326403 9 feb 20.07 libgcrypt.so.11.5.3 -rwxr-xr-x 1 jas jas 11162 9 feb 20.06 libgpg-error.so.0.5.0 -rw-r--r-- 1 jas jas 75618 9 feb 20.02 libpthread-0.9.30.1.so -rw-r--r-- 1 jas jas 1077339 9 feb 20.13 libcrypto.so.0.9.8 Thus the results would be: AXTLS: 75kb no dependencies? CyaSSL: 144kb no dependencies? GnuTLS: 548kb zlib 66kb libgcrypt 326kb libgpg-error 11kb => 951kb MatrixSSL: 82kb (+pthread 76kb) => 82/158kb OpenSSL: 249kb libcrypto 1077kb => 1326kb PolarSSL: 211kb no dependencies? Libpthread is part of base-files, so I'm not sure it is fair to include it as a dependency of MatrixSSL but none of the other libraries depended on libpthread so it should be mentioned. Note that GnuTLS's zlib support could be disabled (which is done by at least OpenSSL and CyaSSL) to save the 66kb from zlib and likely a few kb's in GnuTLS too, resulting in a ~880kb size for GnuTLS. And finally note that the abilities of the libraries are very different. For example, both OpenSSL and GnuTLS are large projects that contains many things that are useful but not strictly necessary by a TLS implementation. The supported features of some projects are mentioned on this page http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations however the builds in OpenWRT disable some of the features. I'm curious how small you could get GnuTLS if you really tried... /Simon From meissner at suse.de Thu Feb 10 16:40:42 2011 From: meissner at suse.de (Marcus Meissner) Date: Thu, 10 Feb 2011 16:40:42 +0100 Subject: typo in assignment Message-ID: <20110210154042.GI28764@suse.de> Hi, gnutls 2.8.6, lib/gnutls_state.c, around line 200: session->internals.proposed_record_size = DEFAULT_MAX_RECORD_SIZE; session->internals.adv_version_major = 0; session->internals.adv_version_minor = 0; session->internals.v2_hello = 0; memset (&session->internals.handshake_header_buffer, 0, sizeof (handshake_header_buffer_st)); session->internals.adv_version_minor = 0; // <<< session->internals.adv_version_minor = 0; // <<< session->internals.direction = 0; I think one of those marked lines should be session->internals.adv_version_major = 0; // <<< Ciao, Marcus From nmav at gnutls.org Fri Feb 11 09:06:58 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Feb 2011 09:06:58 +0100 Subject: typo in assignment In-Reply-To: <20110210154042.GI28764@suse.de> References: <20110210154042.GI28764@suse.de> Message-ID: <4D54EE22.40306@gnutls.org> On 02/10/2011 04:40 PM, Marcus Meissner wrote: > Hi, > gnutls 2.8.6, lib/gnutls_state.c, around line 200: > session->internals.adv_version_major = 0; > session->internals.adv_version_minor = 0; [...] > session->internals.adv_version_minor = 0; // <<< > session->internals.adv_version_minor = 0; // <<< > I think one of those marked lines should be > session->internals.adv_version_major = 0; // <<< You are right, but they are also superfluous, since the same assignment was being done few lines above. I've removed those lines completely. Thank you for reporting that. regards, Nikos From grothoff at net.in.tum.de Fri Feb 11 10:22:32 2011 From: grothoff at net.in.tum.de (Christian Grothoff) Date: Fri, 11 Feb 2011 10:22:32 +0100 Subject: segfault in _gnutls_recv_server_certificate on FreeBSD (GnuTLS/2.9.10) Message-ID: <201102111022.32194.grothoff@net.in.tum.de> Hi! We've had a report of a segfault on FreeBSD in the GNU libmicrohttpd (MHD) bugtracker. I don't see how MHD could be at fault here, I suspect this is a GnuTLS issue: https://gnunet.org/bugs/view.php?id=1603 Please let me know if you find out or know anything about this issue... Happy hacking, Christian From raitis.krikis at gmail.com Fri Feb 11 19:42:44 2011 From: raitis.krikis at gmail.com (Raitis =?utf-8?b?S3JpxLdpcw==?=) Date: Fri, 11 Feb 2011 18:42:44 +0000 (UTC) Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice References: <20101122001723.70acc8e0@i7katze> Message-ID: Hi, I was wondering if someone could send me the command-line code to make gnuTLS use OpenSSL? -Thanks. From nmav at gnutls.org Sat Feb 12 19:49:37 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Feb 2011 19:49:37 +0100 Subject: segfault in _gnutls_recv_server_certificate on FreeBSD (GnuTLS/2.9.10) In-Reply-To: <201102111022.32194.grothoff@net.in.tum.de> References: <201102111022.32194.grothoff@net.in.tum.de> Message-ID: <4D56D641.7040404@gnutls.org> On 02/11/2011 10:22 AM, Christian Grothoff wrote: > Hi! > > We've had a report of a segfault on FreeBSD in the GNU libmicrohttpd (MHD) > bugtracker. I don't see how MHD could be at fault here, I suspect this is a > GnuTLS issue: > https://gnunet.org/bugs/view.php?id=1603 > Please let me know if you find out or know anything about this issue... Could you please provide the information on list? The site you reference requires login. regards, Nikos From grothoff at net.in.tum.de Sat Feb 12 20:22:12 2011 From: grothoff at net.in.tum.de (Christian Grothoff) Date: Sat, 12 Feb 2011 20:22:12 +0100 Subject: segfault in _gnutls_recv_server_certificate on FreeBSD (GnuTLS/2.9.10) In-Reply-To: <4D56D641.7040404@gnutls.org> References: <201102111022.32194.grothoff@net.in.tum.de> <4D56D641.7040404@gnutls.org> Message-ID: <201102122022.12831.grothoff@net.in.tum.de> On Saturday, February 12, 2011 07:49:37 pm Nikos Mavrogiannopoulos wrote: > On 02/11/2011 10:22 AM, Christian Grothoff wrote: > > Hi! > > > > We've had a report of a segfault on FreeBSD in the GNU libmicrohttpd > > (MHD) bugtracker. I don't see how MHD could be at fault here, I suspect > > this is a GnuTLS issue: > > https://gnunet.org/bugs/view.php?id=1603 > > Please let me know if you find out or know anything about this issue... > > Could you please provide the information on list? The site you > reference requires login. > > regards, > Nikos Sure. 0001603: SEGFAULT in tls_session_time_out_test Description FreeBSD 8.1 i386 libmicrohttpd latest SVN version curl -V: curl 7.21.1 (i386-unknown-freebsd8.1) libcurl/7.21.1 GnuTLS/2.9.10 zlib/1.2.3 Protocols: dict file ftp ftps http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp Features: IPv6 Largefile NTLM SSL libz Additional Information make check-TESTS curl version: libcurl/7.21.1 GnuTLS/2.9.10 zlib/1.2.3 curl_easy_perform failed: `Timeout was reached' Error: received handshake message out of context PASS: tls_daemon_options_test PASS: mhds_multi_daemon_test PASS: mhds_get_test PASS: mhds_get_test_select PASS: mhds_session_info_test PASS: tls_thread_mode_test PASS: tls_multi_thread_mode_test Segmentation fault (core dumped) FAIL: tls_session_time_out_test PASS: tls_authentication_test ====================================== 1 of 9 tests failed Please report to libmicrohttpd at gnu.org ====================================== *** Error code 1 Stop in /root/libmicrohttpd/src/testcurl/https. *** Error code 1 [root at freebsd8 ~/libmicrohttpd/src/testcurl/https]# valgrind .libs/tls_session_time_out_test ==6671== Memcheck, a memory error detector ==6671== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6671== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==6671== Command: .libs/tls_session_time_out_test ==6671== vex x86->IR: unhandled instruction bytes: 0xF4 0xED 0xBF 0xBE ==6671== Invalid read of size 1 ==6671== at 0xBEBFECDB: ??? ==6671== by 0xCFCA1: _gnutls_recv_server_certificate (in /usr/local/lib/libgnutls.so.42) ==6671== by 0xCC66D: _gnutls_handshake_client (in /usr/local/lib/libgnutls.so.42) ==6671== by 0xCD377: gnutls_handshake (in /usr/local/lib/libgnutls.so.42) ==6671== by 0x804915F: main (tls_session_time_out_test.c:68) ==6671== Address 0xb9bec0ab is not stack'd, malloc'd or (recently) free'd ==6671== ==6671== ==6671== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6671== Access not within mapped region at address 0xB9BEC0AB ==6671== at 0xBEBFECDB: ??? ==6671== by 0xCFCA1: _gnutls_recv_server_certificate (in /usr/local/lib/libgnutls.so.42) ==6671== by 0xCC66D: _gnutls_handshake_client (in /usr/local/lib/libgnutls.so.42) ==6671== by 0xCD377: gnutls_handshake (in /usr/local/lib/libgnutls.so.42) ==6671== by 0x804915F: main (tls_session_time_out_test.c:68) ==6671== If you believe this happened as a result of a stack ==6671== overflow in your program's main thread (unlikely but ==6671== possible), you can try to increase the size of the ==6671== main thread stack using the --main-stacksize= flag. ==6671== The main thread stack size used in this run was 16777216. ==6671== ==6671== HEAP SUMMARY: ==6671== in use at exit: 105,213 bytes in 1,454 blocks ==6671== total heap usage: 11,767 allocs, 10,313 frees, 671,300 bytes allocated ==6671== ==6671== LEAK SUMMARY: ==6671== definitely lost: 1,024 bytes in 1 blocks ==6671== indirectly lost: 0 bytes in 0 blocks ==6671== possibly lost: 0 bytes in 0 blocks ==6671== still reachable: 104,189 bytes in 1,453 blocks ==6671== suppressed: 0 bytes in 0 blocks ==6671== Rerun with --leak-check=full to see details of leaked memory ==6671== ==6671== For counts of detected and suppressed errors, rerun with: -v ==6671== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Killed: 9 Thanks! Christian From nmav at gnutls.org Sat Feb 12 22:03:31 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Feb 2011 22:03:31 +0100 Subject: segfault in _gnutls_recv_server_certificate on FreeBSD (GnuTLS/2.9.10) In-Reply-To: <201102122022.12831.grothoff@net.in.tum.de> References: <201102111022.32194.grothoff@net.in.tum.de> <4D56D641.7040404@gnutls.org> <201102122022.12831.grothoff@net.in.tum.de> Message-ID: <4D56F5A3.3050607@gnutls.org> On 02/12/2011 08:22 PM, Christian Grothoff wrote: > 0001603: SEGFAULT in tls_session_time_out_test Description FreeBSD > 8.1 i386 libmicrohttpd latest SVN version Sorry I just noticed that your gnutls version is of an old development release. Does the problem persist with a stable release such as 2.10.x? regards, Nikos From ametzler at downhill.at.eu.org Wed Feb 16 19:44:08 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 16 Feb 2011 19:44:08 +0100 Subject: included PaKChoiS library license Message-ID: <20110216184408.GA1998@downhill.g.la> Hello, just for clarfication: Am I correct in assuming that the PaKChoiS library (including the copy shipped with GnuTLS) is not a GNU project, i.e. the copyright has not been assigned to FSF? thanks in advance cu andreas From nmav at gnutls.org Wed Feb 16 19:56:42 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 16 Feb 2011 19:56:42 +0100 Subject: included PaKChoiS library license In-Reply-To: <20110216184408.GA1998@downhill.g.la> References: <20110216184408.GA1998@downhill.g.la> Message-ID: <4D5C1DEA.3070306@gnutls.org> On 02/16/2011 07:44 PM, Andreas Metzler wrote: > Hello, > just for clarfication: Am I correct in assuming that the PaKChoiS > library (including the copy shipped with GnuTLS) is not a GNU project, > i.e. the copyright has not been assigned to FSF? Yes you are correct... Does this affect you in any way? regards, Nikos From ametzler at downhill.at.eu.org Wed Feb 16 20:11:19 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 16 Feb 2011 20:11:19 +0100 Subject: included PaKChoiS library license In-Reply-To: <4D5C1DEA.3070306@gnutls.org> References: <20110216184408.GA1998@downhill.g.la> <4D5C1DEA.3070306@gnutls.org> Message-ID: <20110216191119.GB1998@downhill.g.la> On 2011-02-16 Nikos Mavrogiannopoulos wrote: > On 02/16/2011 07:44 PM, Andreas Metzler wrote: > > Hello, > > just for clarfication: Am I correct in assuming that the PaKChoiS > > library (including the copy shipped with GnuTLS) is not a GNU project, > > i.e. the copyright has not been assigned to FSF? > Yes you are correct... Does this affect you in any way? [...] Thanks for the quick response. It is no problem, I just wanted to make sure that the information in debian/copyright is going to be correct. cu andreas From jos at kuijpersvof.nl Thu Feb 17 19:41:28 2011 From: jos at kuijpersvof.nl (Jos Kuijpers) Date: Thu, 17 Feb 2011 19:41:28 +0100 Subject: Objective-C binding for ObjFW Message-ID: <014b01cbced2$49fd6b70$ddf84250$@kuijpersvof.nl> Hi all, I am writing a library for the objective-C framework ObjFW (https://webkeks.org/objfw https://webkeks.org/hg/objfw), which is not written by me. The normal socket class has connect, close, bind, read and write, and I am just overwriting those. My library is located at https://webkeks.org/hg/objgnutls. Does anyone know a (little) objective-c, enough to take a look at my code, and willing to do so? I would like to know whether I am doing it the right way. With kind regards, Jos From ametzler at downhill.at.eu.org Thu Feb 17 20:00:09 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 17 Feb 2011 20:00:09 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? Message-ID: <20110217190009.GB2459@downhill.g.la> Hello, I think the the ABI in 2.11.6 was changed relative to 2.10. Considering the recent discussion on list I guess this was not done intentionally. --- gnutls-2.10.4/lib/includes/gnutls/crypto.h 2010-08-01 22:37:50.000000000 +0 200 +++ gnutls-2.11.6/lib/includes/gnutls/crypto.h 2010-12-06 17:28:51.000000000 +0 100 [...] @@ -85,17 +91,22 @@ typedef struct typedef struct { int (*init) (gnutls_mac_algorithm_t, void **ctx); int (*setkey) (void *ctx, const void *key, size_t keysize); int (*hash) (void *ctx, const void *text, size_t textsize); - int (*copy) (void **dst_ctx, void *src_ctx); int (*output) (void *src_ctx, void *digest, size_t digestsize); void (*deinit) (void *ctx); } gnutls_crypto_mac_st; A member of a public struct was deleted, changing the size of the struct. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Thu Feb 17 23:13:29 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Feb 2011 23:13:29 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <20110217190009.GB2459@downhill.g.la> References: <20110217190009.GB2459@downhill.g.la> Message-ID: <4D5D9D89.50308@gnutls.org> On 02/17/2011 08:00 PM, Andreas Metzler wrote: > Hello, > > I think the the ABI in 2.11.6 was changed relative to 2.10. > Considering the recent discussion on list I guess this was not done > intentionally. That part of the API concerns gnutls internals thus it is always under revision. However it will not cause any crashes since it relies on GNUTLS_CRYPTO_API_VERSION number to detect the version of the structures supplied. The catch is that applications that replace gnutls's internals will need recompilation every time... regards, Nikos From david.kirkby at onetel.net Fri Feb 18 12:03:07 2011 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Fri, 18 Feb 2011 11:03:07 +0000 Subject: support for AIX and HP-UX In-Reply-To: <4D5D9FAD.2090805@gnutls.org> References: <1545624608.12790.1297951952441.JavaMail.apache@mail21.abv.bg> <4D5D5BAE.8000708@onetel.net> <4D5D9FAD.2090805@gnutls.org> Message-ID: <4D5E51EB.2030801@onetel.net> On 02/17/11 10:22 PM, Nikos Mavrogiannopoulos wrote: > On 02/17/2011 06:32 PM, Dr. David Kirkby wrote: >> On 02/17/11 02:50 PM, Nikos Mavrogiannopoulos wrote: >>> On Thu, Feb 17, 2011 at 3:12 PM, derleader mail wrote: >>>> Hi, >>>> I'm interested is it possible to use GnuTLS with IBM AIX and >>>> HP-UX? I need >>>> to develop a application which uses GnuTLS for secure communication >>>> on these >>>> platforms. >>> >>> You shouldn't have any problem on these platforms since they are >>> supposed to be >>> POSIX compliant. If you have any issue report it as bug. >>> >>> regards, >>> Nikos >> >> I had problems when trying to build GnuTLS on both AIX and HP-UX, as >> part of the Sage maths program. Though this was with a rather old >> version of GnuTLS (2.2.1) >> >> Here's the issue I had on AIX 5.3 >> http://trac.sagemath.org/sage_trac/ticket/9975 >> Here's the issue I had on HP-UX 11.11B >> http://trac.sagemath.org/sage_trac/ticket/7511 >> (note I did report this HP-UX. I don't recall getting any feedback, but >> I may have done). > > As I can understand from the logs, the gnutls-serv and gnutls-cli > programs do not build. Does this affect you on using the library? > > regards, > Nikos To be honest I don't know. I did not spend a lot of time on this, as I was only looking to see what components of Sage (there are about 100 of them) would build on AIX and HP-UX, and which would not. This was mainly to see the likelihood of porting Sage to those platforms. At least in the version we use (2.2.1) there does not appear to be any configure options to disable the build of gnutls-serv and gnutls-cli. Is there in the latest? If anyone wanted access to the AIX or HP-UX hardware for testing, I could provide it. But due to power consumption of these machines, they don't run 24/7, so it would have to be by arrangement, but I don't mind leaving them on a week or so. (The power bill is paid by me personally, as these are my own personal hardware in my house). Dave From ametzler at downhill.at.eu.org Fri Feb 18 18:10:04 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 18 Feb 2011 18:10:04 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D5D9D89.50308@gnutls.org> References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> Message-ID: <20110218171004.GA2462@downhill.g.la> On 2011-02-17 Nikos Mavrogiannopoulos wrote: > On 02/17/2011 08:00 PM, Andreas Metzler wrote: > > Hello, > > > > I think the the ABI in 2.11.6 was changed relative to 2.10. > > Considering the recent discussion on list I guess this was not done > > intentionally. > That part of the API concerns gnutls internals thus it is always > under revision. [...] Stupid question: If it is about internals why is it part of the published API/ABI? 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 Fri Feb 18 19:31:45 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Feb 2011 19:31:45 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D5D9D89.50308@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 17 Feb 2011 23:13:29 +0100") References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> Message-ID: <871v355h4e.fsf@vigenere.g10code.de> On Thu, 17 Feb 2011 23:13, nmav at gnutls.org said: > That part of the API concerns gnutls internals thus it is always > under revision. However it will not cause any crashes since it relies > on GNUTLS_CRYPTO_API_VERSION number to detect the version of the > structures supplied. The catch is that applications that replace Okay, but in this case you should make it clear that gnutls_crypto_mac_register2 and gnutls_crypto_digest_register2 are private functions; for example by prefixing them with an underscore. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Sat Feb 19 10:14:30 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 19 Feb 2011 10:14:30 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <20110218171004.GA2462@downhill.g.la> References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> Message-ID: <4D5F89F6.3040009@gnutls.org> On 02/18/2011 06:10 PM, Andreas Metzler wrote: > On 2011-02-17 Nikos Mavrogiannopoulos wrote: >> On 02/17/2011 08:00 PM, Andreas Metzler wrote: >>> Hello, >>> >>> I think the the ABI in 2.11.6 was changed relative to 2.10. >>> Considering the recent discussion on list I guess this was not done >>> intentionally. > >> That part of the API concerns gnutls internals thus it is always >> under revision. > [...] > Stupid question: If it is about internals why is it part of the > published API/ABI? That's a nice question. This API is mostly interesting to people who are porting gnutls to another crypto library. We might exported via another header in gnutls-3.0.0. regards, Nikos From wk at gnupg.org Sat Feb 19 10:38:24 2011 From: wk at gnupg.org (Werner Koch) Date: Sat, 19 Feb 2011 10:38:24 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D5F89F6.3040009@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 19 Feb 2011 10:14:30 +0100") References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> Message-ID: <87wrkw4b5b.fsf@vigenere.g10code.de> On Sat, 19 Feb 2011 10:14, nmav at gnutls.org said: > That's a nice question. This API is mostly interesting to people > who are porting gnutls to another crypto library. We might An API is an API, is an API. You need to make clear which functions are part of the API and which are not. The usual way to do this in GNU and most other FS programs is to either prefix the names with an underscore or have somthing like "_private_" as part of the function name. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Sat Feb 19 10:47:07 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 19 Feb 2011 10:47:07 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <87wrkw4b5b.fsf@vigenere.g10code.de> References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> Message-ID: <4D5F919B.90902@gnutls.org> On 02/19/2011 10:38 AM, Werner Koch wrote: > On Sat, 19 Feb 2011 10:14, nmav at gnutls.org said: > >> That's a nice question. This API is mostly interesting to people >> who are porting gnutls to another crypto library. We might > > An API is an API, is an API. Indeed but it doesn't have to be stable. That part was intended to change often by design. regards, Nikos From simon at josefsson.org Sat Feb 19 16:17:05 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Feb 2011 16:17:05 +0100 Subject: Objective-C binding for ObjFW In-Reply-To: <014b01cbced2$49fd6b70$ddf84250$@kuijpersvof.nl> (Jos Kuijpers's message of "Thu, 17 Feb 2011 19:41:28 +0100") References: <014b01cbced2$49fd6b70$ddf84250$@kuijpersvof.nl> Message-ID: <87sjvkhx5a.fsf@latte.josefsson.org> "Jos Kuijpers" writes: > Hi all, > > I am writing a library for the objective-C framework ObjFW > (https://webkeks.org/objfw https://webkeks.org/hg/objfw), which is not > written by me. > The normal socket class has connect, close, bind, read and write, and I am > just overwriting those. My library is located at > https://webkeks.org/hg/objgnutls. > > Does anyone know a (little) objective-c, enough to take a look at my code, > and willing to do so? I would like to know whether I am doing it the right > way. I don't know objective-c, but some quick comments: * GnuTLS is designed in a OO-inspired way, and in particular the authentication objects (X.509 cert, OpenPGP key etc) are their own objects, which can be associated with a session. Thus instead of having a single entry point 'connectToHost' consider if you could split the API up to more closely match the GnuTLS API where credentials are there own objects and associated to each session. Sessions can be short lived but credentials are long-lived, especially for servers. Of course, you can build connectToHost using the other functions, but the flexibility will be there for callers. * Do you need to expose isResumed? Maybe get it via the information dictionary? * What's the point of mustSupportSessionResuming? * Expose the priority string to the caller, rather than hard coding "NORMAL". It is a nice way to get applications to be able to influence low-level stuff in GnuTLS. /Simon From simon at josefsson.org Sat Feb 19 16:20:38 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Feb 2011 16:20:38 +0100 Subject: support for AIX and HP-UX In-Reply-To: <4D5E51EB.2030801@onetel.net> (David Kirkby's message of "Fri, 18 Feb 2011 11:03:07 +0000") References: <1545624608.12790.1297951952441.JavaMail.apache@mail21.abv.bg> <4D5D5BAE.8000708@onetel.net> <4D5D9FAD.2090805@gnutls.org> <4D5E51EB.2030801@onetel.net> Message-ID: <87oc68hwzd.fsf@latte.josefsson.org> "Dr. David Kirkby" writes: > At least in the version we use (2.2.1) there does not appear to be any > configure options to disable the build of gnutls-serv and > gnutls-cli. Is there in the latest? Nope -- but to achieve the same thing you could replace 'make' with 'make -C lib && make -C libextra && ...' or similar. /Simon From simon at josefsson.org Sat Feb 19 16:30:10 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Feb 2011 16:30:10 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D5F919B.90902@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 19 Feb 2011 10:47:07 +0100") References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> <4D5F919B.90902@gnutls.org> Message-ID: <87k4gwhwjh.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > On 02/19/2011 10:38 AM, Werner Koch wrote: >> On Sat, 19 Feb 2011 10:14, nmav at gnutls.org said: >> >>> That's a nice question. This API is mostly interesting to people >>> who are porting gnutls to another crypto library. We might >> >> An API is an API, is an API. > > Indeed but it doesn't have to be stable. That part was intended to > change often by design. I don't think that is wise in the long run -- if we want people to use the APIs they must be stable. If they aren't intended to be stable, it is better to mark them as private functions by prefixing them with _gnutls instead or similar. /Simon From nmav at gnutls.org Sat Feb 19 19:56:23 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 19 Feb 2011 19:56:23 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <87k4gwhwjh.fsf@latte.josefsson.org> References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> <4D5F919B.90902@gnutls.org> <87k4gwhwjh.fsf@latte.josefsson.org> Message-ID: <4D601257.4040002@gnutls.org> On 02/19/2011 04:30 PM, Simon Josefsson wrote: >>>> That's a nice question. This API is mostly interesting to people >>>> who are porting gnutls to another crypto library. We might >>> An API is an API, is an API. >> Indeed but it doesn't have to be stable. That part was intended to >> change often by design. > I don't think that is wise in the long run -- if we want people to use > the APIs they must be stable. If they aren't intended to be stable, it > is better to mark them as private functions by prefixing them with > _gnutls instead or similar. Indeed, but the API is already there. If we now add an underscore, then we would break ABI... We could modify them in version 3 that breaks the ABI anyway. regards, Nikos From ametzler at downhill.at.eu.org Sun Feb 20 09:35:08 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 20 Feb 2011 09:35:08 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc Message-ID: <20110220083508.GA2038@downhill.g.la> Hello, I have uploaded 2.11.6 to debian/experimental to get some test builds. It did not go too bad, successful builds on amd64, armel, i386, ia64 and kfreebsd-*, but the resume test failed on multiple archs (powerpc s390 and sparc). The error is reproducible on e.g. s390. -------------------------- (sid)ametzler at zelenka:~/GNUTLS/gnutls26-2.11.6/tests$ ./resume client: Handshake failed GnuTLS error: GnuTLS internal error. server: Handshake has failed (A TLS packet with unexpected length was received.) Self test `./resume.rpath' finished with 1 errors -------------------------- 2.10.4 continues to work: -------------------------- (sid)ametzler at zelenka:~/GNUTLS/gnutls26-2.11.6/tests$ chrpath -d resume (sid)ametzler at zelenka:~/GNUTLS/gnutls26-2.11.6/tests$ ./resume Self test `./resume' finished with 0 errors -------------------------- 2.11.6 was built with --with-libgcrypt. Complete build logs are available here https://buildd.debian.org/status/package.php?p=gnutls26&suite=experimental cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ametzler at downhill.at.eu.org Sun Feb 20 11:23:37 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 20 Feb 2011 11:23:37 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87k4gvgjx4.fsf@latte.josefsson.org> References: <87k4gvgjx4.fsf@latte.josefsson.org> Message-ID: <20110220102337.GC2038@downhill.g.la> On 2011-02-20 Simon Josefsson wrote: > The Blowfish code in Nettle has already been re-implemented under > LGPLv2+ but not released yet. I am working on re-implementing Serpent > under LGPLv2+, however there are multiple and incompatible test vectors > of Serpent and it is not clear which corresponds to the "real" Serpent. > Meanwhile, perhaps the Nettle package in Debian could disable Serpent > and Blowfish, or since the Blowfish re-write mostly re-established > LGPLv2+ as the license of the old code, at least disable Serpent? [...] Hello, That would break the ABI and require a soname change, afaiui. I have the feeling that the discussion I started is an academic one anyway. Nettle's public key library (libhogweed) uses and links against libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to nettle would break GPLv2-compatibility (GPLv2 without the "or any later version " clause). Oh dear. 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 Feb 20 15:33:50 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 20 Feb 2011 15:33:50 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <20110220102337.GC2038@downhill.g.la> (Andreas Metzler's message of "Sun, 20 Feb 2011 11:23:37 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> Message-ID: <87r5b2epwx.fsf@latte.josefsson.org> Andreas Metzler writes: > On 2011-02-20 Simon Josefsson wrote: >> The Blowfish code in Nettle has already been re-implemented under >> LGPLv2+ but not released yet. I am working on re-implementing Serpent >> under LGPLv2+, however there are multiple and incompatible test vectors >> of Serpent and it is not clear which corresponds to the "real" Serpent. > >> Meanwhile, perhaps the Nettle package in Debian could disable Serpent >> and Blowfish, or since the Blowfish re-write mostly re-established >> LGPLv2+ as the license of the old code, at least disable Serpent? > [...] > > Hello, > That would break the ABI and require a soname change, afaiui. Fixing Serpent would probably require the same, since the current implementation isn't compatible with (for example) Libgcrypt. > I have the feeling that the discussion I started is an academic one > anyway. Nettle's public key library (libhogweed) uses and links against > libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to > nettle would break GPLv2-compatibility (GPLv2 without the "or any > later version " clause). Oh dear. It has been discussed to dual-license some libraries under GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way out here. GnuTLS 2.12 is not released (and there is not even any release candidates), so we still have time to resolve this in a good way. (I've changed gnutls-dev at gnupg.org into gnutls-devel at gnu.org which is the current list address.) /Simon From ametzler at downhill.at.eu.org Sun Feb 20 15:54:33 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 20 Feb 2011 15:54:33 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87r5b2epwx.fsf@latte.josefsson.org> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <87r5b2epwx.fsf@latte.josefsson.org> Message-ID: <20110220145433.GD2038@downhill.g.la> On 2011-02-20 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > I have the feeling that the discussion I started is an academic one > > anyway. Nettle's public key library (libhogweed) uses and links against > > libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to > > nettle would break GPLv2-compatibility (GPLv2 without the "or any > > later version " clause). Oh dear. > It has been discussed to dual-license some libraries under > GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way > out here. GnuTLS 2.12 is not released (and there is not even any > release candidates), so we still have time to resolve this in a good > way. [...] Hello, Afaik there is nothing GnuTLS can do. It is using the most permissive license of the involved packages. The culprit is the combination of third party (L)GPL-v2only software (e.g. cups) with libgmp, which switched from LGPLv2+ to LGPLv3+ in 4.2.2. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sun Feb 20 15:58:04 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Feb 2011 15:58:04 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87r5b2epwx.fsf@latte.josefsson.org> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <87r5b2epwx.fsf@latte.josefsson.org> Message-ID: <4D612BFC.3060201@gnutls.org> On 02/20/2011 03:33 PM, Simon Josefsson wrote: > It has been discussed to dual-license some libraries under > GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way > out here. GnuTLS 2.12 is not released (and there is not even any > release candidates), so we still have time to resolve this in a good > way. gnutls 2.12 doesn't depend on libnettle only. It can be used with libgcrypt as well thus I don't think this should be a stopper for gnutls 2.12. We should release 2.12 and once this issue is resolved debian can link with nettle (The abi doesn't break with this change). regards, Nikos From nmav at gnutls.org Sun Feb 20 16:12:39 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Feb 2011 16:12:39 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <20110220102337.GC2038@downhill.g.la> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> Message-ID: <4D612F67.6080909@gnutls.org> On 02/20/2011 11:23 AM, Andreas Metzler wrote: > Hello, That would break the ABI and require a soname change, afaiui. > > I have the feeling that the discussion I started is an academic one > anyway. Nettle's public key library (libhogweed) uses and links > against libgmp, which is LGPLv3+. Therefore switching gnutls from > gcrypt to nettle would break GPLv2-compatibility (GPLv2 without the > "or any later version " clause). Oh dear. That's pretty bad news... Although it doesn't affect 2.12 too seriously. nettle was a factor of 2x faster in the combination of AES/RSA/SHA-1 in the software implementation of algorithms (no asm except for gmp), and didn't impose restrictions on the applications that used it (i.e. suid/non-suid), thus it was selected for default back-end of gnutls. However since in 2.12 all the features used by gnutls are supported by libgcrypt there is no problem for debian linking with it[0]. regards, Nikos [0]. This might be an issue in later releases that support the GCM ciphersuites (in master only) that are not supported by libgcrypt. From wk at gnupg.org Sun Feb 20 17:20:57 2011 From: wk at gnupg.org (Werner Koch) Date: Sun, 20 Feb 2011 17:20:57 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D601257.4040002@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 19 Feb 2011 19:56:23 +0100") References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> <4D5F919B.90902@gnutls.org> <87k4gwhwjh.fsf@latte.josefsson.org> <4D601257.4040002@gnutls.org> Message-ID: <87sjvi4qza.fsf@vigenere.g10code.de> On Sat, 19 Feb 2011 19:56, nmav at gnutls.org said: > Indeed, but the API is already there. If we now add an underscore, then > we would break ABI... We could modify them in version 3 that breaks > the ABI anyway. Sure. Fixing an broken ABI be breaking it again might indeed not be a good idea. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Sun Feb 20 16:21:02 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Feb 2011 16:21:02 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <20110220083508.GA2038@downhill.g.la> References: <20110220083508.GA2038@downhill.g.la> Message-ID: <4D61315E.9040600@gnutls.org> On 02/20/2011 09:35 AM, Andreas Metzler wrote: > Hello, > > I have uploaded 2.11.6 to debian/experimental to get some test > builds. It did not go too bad, successful builds on amd64, armel, > i386, ia64 and kfreebsd-*, but the resume test failed on multiple > archs (powerpc s390 and sparc). The error is reproducible on e.g. > s390. I suppose it is an issue with big-endian systems only? Unfortunately I don't have access to any of them... If you or anyone else with access to such system, could locate the error using "git bisect", would be really helpful! regards, Nikos From simon at josefsson.org Sun Feb 20 17:33:45 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 20 Feb 2011 17:33:45 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <20110220145433.GD2038@downhill.g.la> (Andreas Metzler's message of "Sun, 20 Feb 2011 15:54:33 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <87r5b2epwx.fsf@latte.josefsson.org> <20110220145433.GD2038@downhill.g.la> Message-ID: <87ipwebr86.fsf@latte.josefsson.org> Andreas Metzler writes: > On 2011-02-20 Simon Josefsson wrote: >> Andreas Metzler writes: > [...] > >> > I have the feeling that the discussion I started is an academic one >> > anyway. Nettle's public key library (libhogweed) uses and links against >> > libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to >> > nettle would break GPLv2-compatibility (GPLv2 without the "or any >> > later version " clause). Oh dear. > >> It has been discussed to dual-license some libraries under >> GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way >> out here. GnuTLS 2.12 is not released (and there is not even any >> release candidates), so we still have time to resolve this in a good >> way. > [...] > > Hello, > Afaik there is nothing GnuTLS can do. It is using the most permissive > license of the involved packages. The culprit is the combination of > third party (L)GPL-v2only software (e.g. cups) with libgmp, which > switched from LGPLv2+ to LGPLv3+ in 4.2.2. The FSF has clarified that to resolve that problem, it is recommended to dual-license projects under GPLv2+/LGPLv3+ see: http://www.gnu.org/prep/maintain/maintain.html#Licensing-of-GNU-Packages So if GMP follows this suggestion, the problem would be resolved for GPLv2-only projects. Did you really notice any LGPLv2-only projects using GnuTLS when you looked? /Simon From ametzler at downhill.at.eu.org Sun Feb 20 20:06:29 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 20 Feb 2011 20:06:29 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <4D61315E.9040600@gnutls.org> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> Message-ID: <20110220190629.GE2038@downhill.g.la> On 2011-02-20 Nikos Mavrogiannopoulos wrote: > On 02/20/2011 09:35 AM, Andreas Metzler wrote: > > Hello, > > > > I have uploaded 2.11.6 to debian/experimental to get some test > > builds. It did not go too bad, successful builds on amd64, armel, > > i386, ia64 and kfreebsd-*, but the resume test failed on multiple > > archs (powerpc s390 and sparc). The error is reproducible on e.g. > > s390. > I suppose it is an issue with big-endian systems only? Unfortunately > I don't have access to any of them... If you or anyone else with access > to such system, could locate the error using "git bisect", would be > really helpful! I started, but have given up for now since git is incompilable most of the time. (Really, out of a dozen git bisects there are 10 unbuildable checkouts.) The bug is absent in the last 2.9. release but present in 2.11.0. I will revisit when I have hours to spare again. cu andreas From david.kirkby at onetel.net Sun Feb 20 18:47:50 2011 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Sun, 20 Feb 2011 17:47:50 +0000 Subject: support for AIX and HP-UX In-Reply-To: <87oc68hwzd.fsf@latte.josefsson.org> References: <1545624608.12790.1297951952441.JavaMail.apache@mail21.abv.bg> <4D5D5BAE.8000708@onetel.net> <4D5D9FAD.2090805@gnutls.org> <4D5E51EB.2030801@onetel.net> <87oc68hwzd.fsf@latte.josefsson.org> Message-ID: <4D6153C6.7030408@onetel.net> On 02/19/11 03:20 PM, Simon Josefsson wrote: > "Dr. David Kirkby" writes: > >> At least in the version we use (2.2.1) there does not appear to be any >> configure options to disable the build of gnutls-serv and >> gnutls-cli. Is there in the latest? > > Nope -- but to achieve the same thing you could replace 'make' with > 'make -C lib&& make -C libextra&& ...' or similar. > > /Simon Thank you. Clearly a better solution would be to get this fixed properly. When I have some time, I'll build the latest source (or latest snapshot from where ???) and report if that builds or not. Perhaps we can get the full package to build on both AIX and HP-UX. My HP-UX system is not fully POSIX compliant, as the latest version which will run on my hardware is not POSIX. But my AIX 5.3 system is fully POSIX, but gnutls would not build on that either. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave From nmav at gnutls.org Sun Feb 20 21:23:34 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Feb 2011 21:23:34 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <20110220190629.GE2038@downhill.g.la> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> <20110220190629.GE2038@downhill.g.la> Message-ID: <4D617846.5090508@gnutls.org> On 02/20/2011 08:06 PM, Andreas Metzler wrote: > On 2011-02-20 Nikos Mavrogiannopoulos wrote: >> On 02/20/2011 09:35 AM, Andreas Metzler wrote: >>> Hello, >>> >>> I have uploaded 2.11.6 to debian/experimental to get some test >>> builds. It did not go too bad, successful builds on amd64, armel, >>> i386, ia64 and kfreebsd-*, but the resume test failed on multiple >>> archs (powerpc s390 and sparc). The error is reproducible on e.g. >>> s390. > >> I suppose it is an issue with big-endian systems only? Unfortunately >> I don't have access to any of them... If you or anyone else with access >> to such system, could locate the error using "git bisect", would be >> really helpful! > > I started, but have given up for now since git is incompilable most of > the time. (Really, out of a dozen git bisects there are 10 unbuildable > checkouts.) > > The bug is absent in the last 2.9. release > but present in 2.11.0. > > I will revisit when I have hours to spare again. Could you provide the output of the "resume -v"? It might help locating the issue. regards, Nikos From simon at josefsson.org Sun Feb 20 21:31:39 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 20 Feb 2011 21:31:39 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87ipwebr86.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sun, 20 Feb 2011 17:33:45 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <87r5b2epwx.fsf@latte.josefsson.org> <20110220145433.GD2038@downhill.g.la> <87ipwebr86.fsf@latte.josefsson.org> Message-ID: <87zkpq8n2s.fsf@latte.josefsson.org> Simon Josefsson writes: > Andreas Metzler writes: > >> On 2011-02-20 Simon Josefsson wrote: >>> Andreas Metzler writes: >> [...] >> >>> > I have the feeling that the discussion I started is an academic one >>> > anyway. Nettle's public key library (libhogweed) uses and links against >>> > libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to >>> > nettle would break GPLv2-compatibility (GPLv2 without the "or any >>> > later version " clause). Oh dear. >> >>> It has been discussed to dual-license some libraries under >>> GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way >>> out here. GnuTLS 2.12 is not released (and there is not even any >>> release candidates), so we still have time to resolve this in a good >>> way. >> [...] >> >> Hello, >> Afaik there is nothing GnuTLS can do. It is using the most permissive >> license of the involved packages. The culprit is the combination of >> third party (L)GPL-v2only software (e.g. cups) with libgmp, which >> switched from LGPLv2+ to LGPLv3+ in 4.2.2. > > The FSF has clarified that to resolve that problem, it is recommended to > dual-license projects under GPLv2+/LGPLv3+ see: > > http://www.gnu.org/prep/maintain/maintain.html#Licensing-of-GNU-Packages > > So if GMP follows this suggestion, the problem would be resolved for > GPLv2-only projects. Did you really notice any LGPLv2-only projects > using GnuTLS when you looked? I now realize that LGPLv2-only projects is not a problem since LGPLv2-only can be upgraded to GPLv2 which would then be GPLv2-compatible again. So let me rephrase the question: is there any project that happen to combine LGPLv2-only and GPLv2+-incompatible licensed code? Only such a project would be problematic even if GMP would become dual licensed under GPLv2+/LGPLv3+. If we can get any kind of metrics on the scale of this problem, we can think about whether it is a problem worth solving. /Simon From david.kirkby at onetel.net Sun Feb 20 22:52:59 2011 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Sun, 20 Feb 2011 21:52:59 +0000 Subject: Build failure on OpenSolaris machine. Message-ID: <4D618D3B.4020905@onetel.net> I've tried to build GnuTLS on a Sun Ultra 27 (Intel Xeon) running OpenSolaris 06/2009. I've built a lot of software on here without hassle, but the current version of GnuTLS will not build. (Version 2.2.1 builds OK, though I've not tried any other versions). The fact there are copies of the gmp library in both /usr/local/lib and /usr/local/gcc-4.5.0/lib seems to be causing the problem. But there seems no way to specify where the libraries should be found. If one builds gcc, there are options to specify where the gmp library is kept. My GCC is configured with this option. --with-gmp=/usr/local/gcc-4.5.0 but there seems to be no similar option for GnuTLS. $configure checking whether byte ordering is bigendian... no checking for C/C++ restrict keyword... __restrict checking if gcc/ld supports -Wl,--output-def... no checking if LD -Wl,--version-script works... no configure: creating ./config.status config.status: creating Makefile config.status: creating gnutls-extra.pc config.status: creating gl/Makefile config.status: creating includes/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands configure: summary of build options: version: 2.10.4 shared 42:13:16 Host type: i386-pc-solaris2.11 Install prefix: /usr/local Compiler: gcc -std=gnu99 Warning flags: errors: warnings: Library types: Shared=yes, Static=yes Valgrind: no Guile wrappers: yes C++ library: yes OpenSSL library: yes /dev/crypto: no $ make C -DPIC -o .libs/libguile_gnutls_v_1_la-core.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-errors.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-errors.Tpo -c errors.c -fPIC -DPIC -o .libs/libguile_gnutls_v_1_la-errors.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-utils.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-utils.Tpo -c utils.c -fPIC -DPIC -o .libs/libguile_gnutls_v_1_la-utils.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_extra_v_1_la-extra.lo -MD -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c extra.c -fPIC -DPIC -o .libs/libguile_gnutls_extra_v_1_la-extra.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-errors.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-errors.Tpo -c errors.c -o libguile_gnutls_v_1_la-errors.o >/dev/null 2>&1 libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-utils.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-utils.Tpo -c utils.c -o libguile_gnutls_v_1_la-utils.o >/dev/null 2>&1 mv -f .deps/libguile_gnutls_v_1_la-errors.Tpo .deps/libguile_gnutls_v_1_la-errors.Plo libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_extra_v_1_la-extra.lo -MD -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c extra.c -o libguile_gnutls_extra_v_1_la-extra.o >/dev/null 2>&1 mv -f .deps/libguile_gnutls_v_1_la-utils.Tpo .deps/libguile_gnutls_v_1_la-utils.Plo mv -f .deps/libguile_gnutls_extra_v_1_la-extra.Tpo .deps/libguile_gnutls_extra_v_1_la-extra.Plo libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-core.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-core.Tpo -c core.c -o libguile_gnutls_v_1_la-core.o >/dev/null 2>&1 mv -f .deps/libguile_gnutls_v_1_la-core.Tpo .deps/libguile_gnutls_v_1_la-core.Plo /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp -D_REENTRANT -pthreads -g -O2 -o libguile-gnutls-v-1.la -rpath /usr/local/lib libguile_gnutls_v_1_la-core.lo libguile_gnutls_v_1_la-errors.lo libguile_gnutls_v_1_la-utils.lo ../../lib/libgnutls.la ../../lib/gl/liblgnu.la -I/usr/include/gmp -D_REENTRANT -pthreads -lguile -lltdl -lgmp -lsocket -lnsl -lm -lltdl libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libguile-gnutls-v-1.so.0 -o .libs/libguile-gnutls-v-1.so.0.0.0 .libs/libguile_gnutls_v_1_la-core.o .libs/libguile_gnutls_v_1_la-errors.o .libs/libguile_gnutls_v_1_la-utils.o -Wl,-z -Wl,allextract ../../lib/gl/.libs/liblgnu.a -Wl,-z -Wl,defaultextract -R/export/home/drkirkby/gnutls-2.10.4/lib/.libs -R/usr/local/gcc-4.5.0/lib -R/usr/local/lib -R/usr/local/gcc-4.5.0/lib ../../lib/.libs/libgnutls.so -ltasn1 -lz -lgcrypt -lgpg-error /usr/lib/libguile.so -lgmp /usr/local/gcc-4.5.0/lib/libgmp.so -lsocket -lnsl -lm -lltdl -lc -pthreads -pthreads -pthreads ld: fatal: symbol `scm_cell' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); ld: fatal: symbol `scm_double_cell' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); ld: fatal: symbol `scm_array_handle_ref' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); ld: fatal: symbol `scm_array_handle_set' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); ld: fatal: symbol `scm_is_pair' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); ld: fatal: symbol `scm_cell' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); ld: fatal: symbol `scm_double_cell' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); ld: fatal: symbol `scm_array_handle_ref' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); ld: fatal: symbol `scm_array_handle_set' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); ld: fatal: symbol `scm_is_pair' is multiply-defined: (file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); ld: warning: file /usr/local/gcc-4.5.0/lib/libgmp.so: linked to /usr/local/gcc-4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/../../../libgmp.so: attempted multiple inclusion of file ld: fatal: file processing errors. No output written to .libs/libguile-gnutls-v-1.so.0.0.0 collect2: ld returned 1 exit status make[4]: *** [libguile-gnutls-v-1.la] Error 1 make[4]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile/src' make[3]: *** [all] Error 2 make[3]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4' make: *** [all] Error 2 -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave From david.kirkby at onetel.net Sun Feb 20 23:31:05 2011 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Sun, 20 Feb 2011 22:31:05 +0000 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <20110220190629.GE2038@downhill.g.la> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> <20110220190629.GE2038@downhill.g.la> Message-ID: <4D619629.2070605@onetel.net> On 02/20/11 07:06 PM, Andreas Metzler wrote: > On 2011-02-20 Nikos Mavrogiannopoulos wrote: >> On 02/20/2011 09:35 AM, Andreas Metzler wrote: >>> Hello, >>> >>> I have uploaded 2.11.6 to debian/experimental to get some test >>> builds. It did not go too bad, successful builds on amd64, armel, >>> i386, ia64 and kfreebsd-*, but the resume test failed on multiple >>> archs (powerpc s390 and sparc). The error is reproducible on e.g. >>> s390. > >> I suppose it is an issue with big-endian systems only? Unfortunately >> I don't have access to any of them... If you or anyone else with access >> to such system, could locate the error using "git bisect", would be >> really helpful! GnuTLS is used in the Sage maths project. http://www.sagemath.org/ If a developer of GnuTLS needs access to SPARC hardware for testing GnuTLS, then that can almost certainly be arranged via the University of Washington. Sun donated a T5240 (16 core) to the project, which can be used for this sort of thing. Drop me a private email, with a note saying the role you take in GnuTLS development, and a preferred username, and I should be able to arrange it. FWIW, I also have access to HP-UX and AIX hardware. That is personally owned by me, but again others can have access. But due to the power costs, I only run the HP-UX and AIX systems when someone actually wants to do something, whereas the SPARC at the University of Washington is on 24/7. Dave -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From nmav at gnutls.org Mon Feb 21 09:19:44 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Feb 2011 09:19:44 +0100 Subject: Build failure on OpenSolaris machine. In-Reply-To: <4D618D3B.4020905@onetel.net> References: <4D618D3B.4020905@onetel.net> Message-ID: It seems we'll have to add such an option as well. As a quick hack you can use libgcrypt instead of nettle that doesn't depend on libgmp. regards, Nikos On Sun, Feb 20, 2011 at 10:52 PM, Dr. David Kirkby wrote: > I've tried to build GnuTLS on a Sun Ultra 27 (Intel Xeon) running > OpenSolaris 06/2009. I've built a lot of software on here without hassle, > but the current version of GnuTLS will not build. (Version 2.2.1 builds OK, > though I've not tried any other versions). > > The fact there are copies of the gmp library in both /usr/local/lib and > /usr/local/gcc-4.5.0/lib seems to be causing the problem. But there seems no > way to specify where the libraries should be found. > > If one builds gcc, there are options to specify where the gmp library is > kept. > > My GCC is configured with this option. > > --with-gmp=/usr/local/gcc-4.5.0 > > but there seems to be no similar option for GnuTLS. > > $configure > > > > checking whether byte ordering is bigendian... no > checking for C/C++ restrict keyword... __restrict > checking if gcc/ld supports -Wl,--output-def... no > checking if LD -Wl,--version-script works... no > configure: creating ./config.status > config.status: creating Makefile > config.status: creating gnutls-extra.pc > config.status: creating gl/Makefile > config.status: creating includes/Makefile > config.status: creating config.h > config.status: executing depfiles commands > config.status: executing libtool commands > configure: summary of build options: > > ?version: ? ? ? ? ?2.10.4 shared 42:13:16 > ?Host type: ? ? ? ?i386-pc-solaris2.11 > ?Install prefix: ? /usr/local > ?Compiler: ? ? ? ? gcc -std=gnu99 > ?Warning flags: ? ?errors: ?warnings: > ?Library types: ? ?Shared=yes, Static=yes > ?Valgrind: ? ? ? ? no > ?Guile wrappers: ? yes > ?C++ library: ? ? ?yes > ?OpenSSL library: ?yes > ?/dev/crypto: ? ? ?no > > > $ make > > > > C -DPIC -o .libs/libguile_gnutls_v_1_la-core.o > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-errors.lo -MD -MP > -MF .deps/libguile_gnutls_v_1_la-errors.Tpo -c errors.c ?-fPIC -DPIC -o > .libs/libguile_gnutls_v_1_la-errors.o > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-utils.lo -MD -MP > -MF .deps/libguile_gnutls_v_1_la-utils.Tpo -c utils.c ?-fPIC -DPIC -o > .libs/libguile_gnutls_v_1_la-utils.o > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_extra_v_1_la-extra.lo -MD > -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c extra.c ?-fPIC -DPIC > -o .libs/libguile_gnutls_extra_v_1_la-extra.o > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-errors.lo -MD -MP > -MF .deps/libguile_gnutls_v_1_la-errors.Tpo -c errors.c -o > libguile_gnutls_v_1_la-errors.o >/dev/null 2>&1 > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-utils.lo -MD -MP > -MF .deps/libguile_gnutls_v_1_la-utils.Tpo -c utils.c -o > libguile_gnutls_v_1_la-utils.o >/dev/null 2>&1 > mv -f .deps/libguile_gnutls_v_1_la-errors.Tpo > .deps/libguile_gnutls_v_1_la-errors.Plo > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_extra_v_1_la-extra.lo -MD > -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c extra.c -o > libguile_gnutls_extra_v_1_la-extra.o >/dev/null 2>&1 > mv -f .deps/libguile_gnutls_v_1_la-utils.Tpo > .deps/libguile_gnutls_v_1_la-utils.Plo > mv -f .deps/libguile_gnutls_extra_v_1_la-extra.Tpo > .deps/libguile_gnutls_extra_v_1_la-extra.Plo > libtool: compile: ?gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. > -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. > -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 -MT libguile_gnutls_v_1_la-core.lo -MD -MP -MF > .deps/libguile_gnutls_v_1_la-core.Tpo -c core.c -o > libguile_gnutls_v_1_la-core.o >/dev/null 2>&1 > mv -f .deps/libguile_gnutls_v_1_la-core.Tpo > .deps/libguile_gnutls_v_1_la-core.Plo > /bin/sh ../../libtool --tag=CC ? --mode=link gcc -std=gnu99 > -Wno-strict-prototypes ?-I../../lib/gl -I../../lib/gl -I/usr/include/gmp > -D_REENTRANT -pthreads -g -O2 ? -o libguile-gnutls-v-1.la -rpath > /usr/local/lib libguile_gnutls_v_1_la-core.lo > libguile_gnutls_v_1_la-errors.lo libguile_gnutls_v_1_la-utils.lo > ../../lib/libgnutls.la ../../lib/gl/liblgnu.la -I/usr/include/gmp > -D_REENTRANT -pthreads -lguile -lltdl ?-lgmp -lsocket -lnsl -lm -lltdl > libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h > -Wl,libguile-gnutls-v-1.so.0 -o .libs/libguile-gnutls-v-1.so.0.0.0 > .libs/libguile_gnutls_v_1_la-core.o .libs/libguile_gnutls_v_1_la-errors.o > .libs/libguile_gnutls_v_1_la-utils.o ?-Wl,-z -Wl,allextract > ../../lib/gl/.libs/liblgnu.a -Wl,-z -Wl,defaultextract > -R/export/home/drkirkby/gnutls-2.10.4/lib/.libs -R/usr/local/gcc-4.5.0/lib > -R/usr/local/lib -R/usr/local/gcc-4.5.0/lib ../../lib/.libs/libgnutls.so > -ltasn1 -lz -lgcrypt -lgpg-error /usr/lib/libguile.so -lgmp > /usr/local/gcc-4.5.0/lib/libgmp.so -lsocket -lnsl -lm -lltdl -lc ?-pthreads > -pthreads ? -pthreads > ld: fatal: symbol `scm_cell' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); > ld: fatal: symbol `scm_double_cell' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); > ld: fatal: symbol `scm_array_handle_ref' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); > ld: fatal: symbol `scm_array_handle_set' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); > ld: fatal: symbol `scm_is_pair' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-errors.o type=FUNC); > ld: fatal: symbol `scm_cell' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); > ld: fatal: symbol `scm_double_cell' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); > ld: fatal: symbol `scm_array_handle_ref' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); > ld: fatal: symbol `scm_array_handle_set' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); > ld: fatal: symbol `scm_is_pair' is multiply-defined: > ? ? ? ?(file .libs/libguile_gnutls_v_1_la-core.o type=FUNC; file > .libs/libguile_gnutls_v_1_la-utils.o type=FUNC); > ld: warning: file /usr/local/gcc-4.5.0/lib/libgmp.so: linked to > /usr/local/gcc-4.5.0/lib/gcc/i386-pc-solaris2.10/4.5.0/../../../libgmp.so: > attempted multiple inclusion of file > ld: fatal: file processing errors. No output written to > .libs/libguile-gnutls-v-1.so.0.0.0 > collect2: ld returned 1 exit status > make[4]: *** [libguile-gnutls-v-1.la] Error 1 > make[4]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile/src' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4/guile' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/export/home/drkirkby/gnutls-2.10.4' > make: *** [all] Error 2 > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > Dave > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From wk at gnupg.org Mon Feb 21 14:19:25 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Feb 2011 14:19:25 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <4D612F67.6080909@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 20 Feb 2011 16:12:39 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> Message-ID: <87ei714jaa.fsf@vigenere.g10code.de> On Sun, 20 Feb 2011 16:12, nmav at gnutls.org said: > [0]. This might be an issue in later releases that support > the GCM ciphersuites (in master only) that are not supported > by libgcrypt. Nikos, if you need support for GCM it would be a good idea to request such support in libgcrypt. Actually I am slowly preparing for 1.5 and if there is a need for GCM in the near future we should make supre that 1.5 has support for it. We can only implement stuff which we know about. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Mon Feb 21 15:03:14 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Feb 2011 15:03:14 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87ei714jaa.fsf@vigenere.g10code.de> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> Message-ID: Hello Werner, I know... My main issues with libgcrypt are that I got the impression that it is intended to be used as a back-end of gnupg and other uses are not considered or are considered as side-effects... My main issues were: * performance... gcrypt is very slow in the software implementation of AES and SHA-1, comparing to other libraries and nettle... Moreover it uses its own gmp that prevents from including all optimizations added to the original gmp library. * mandates how the library is going to be used by using setuid etc... Why shouldn't a setuid application perform TLS? Indeed there are risks but it should be the application developer to decide, not us. * lack of low level functions to perform RSA/DSA/ECC. * gpg-error... adds a library dependence for something that is really simple and could be part of libgcrypt anyway. For non-gnupg applications there is nothing to be gained by this shared library. Especially performance is a big issue in gnutls, since e.g. in mod_gnutls we can have a server performing crypto with nettle in 50% load, while with libgcrypt the server is on it's capacity at 100% load. Those issues are better in libnettle. However there are also things that are very nice to be in libgcrypt such as: * ECC * transparent usage of AES instructions in the VIA cpu * (the same in the intel/amd CPUs now) * consistent and simple API It would be very nice to have a single gnu crypto library that has all the advantages of both of them. regards, Nikos On Mon, Feb 21, 2011 at 2:19 PM, Werner Koch wrote: > On Sun, 20 Feb 2011 16:12, nmav at gnutls.org said: > >> [0]. This might be an issue in later releases that support >> the GCM ciphersuites (in master only) that are not supported >> by libgcrypt. > > Nikos, if you need support for GCM it would be a good idea to request > such support in libgcrypt. > > Actually I am slowly preparing for 1.5 and if there is a need for GCM in > the near future we should make supre that 1.5 has support for it. ?We > can only implement stuff which we know about. > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > From simon at josefsson.org Mon Feb 21 22:00:16 2011 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 21 Feb 2011 22:00:16 +0100 Subject: support for AIX and HP-UX In-Reply-To: <4D6153C6.7030408@onetel.net> (David Kirkby's message of "Sun, 20 Feb 2011 17:47:50 +0000") References: <1545624608.12790.1297951952441.JavaMail.apache@mail21.abv.bg> <4D5D5BAE.8000708@onetel.net> <4D5D9FAD.2090805@gnutls.org> <4D5E51EB.2030801@onetel.net> <87oc68hwzd.fsf@latte.josefsson.org> <4D6153C6.7030408@onetel.net> Message-ID: <871v31umqn.fsf@latte.josefsson.org> "Dr. David Kirkby" writes: > On 02/19/11 03:20 PM, Simon Josefsson wrote: >> "Dr. David Kirkby" writes: >> >>> At least in the version we use (2.2.1) there does not appear to be any >>> configure options to disable the build of gnutls-serv and >>> gnutls-cli. Is there in the latest? >> >> Nope -- but to achieve the same thing you could replace 'make' with >> 'make -C lib&& make -C libextra&& ...' or similar. >> >> /Simon > > Thank you. > > Clearly a better solution would be to get this fixed properly. When I > have some time, I'll build the latest source (or latest snapshot from > where ???) and report if that builds or not. Perhaps we can get the > full package to build on both AIX and HP-UX. My HP-UX system is not > fully POSIX compliant, as the latest version which will run on my > hardware is not POSIX. > > But my AIX 5.3 system is fully POSIX, but gnutls would not build on that either. I looked at your build log failures and it looks like getaddrinfo and/or sockaddr_storage related problems -- chances are that recent gnulib has fixed those problems. Hopefully we'll get a release candidate out real soon so you can test that. Thanks, Simon From simon at josefsson.org Mon Feb 21 22:04:32 2011 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 21 Feb 2011 22:04:32 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <4D601257.4040002@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 19 Feb 2011 19:56:23 +0100") References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> <4D5F919B.90902@gnutls.org> <87k4gwhwjh.fsf@latte.josefsson.org> <4D601257.4040002@gnutls.org> Message-ID: <87wrktt7z3.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > On 02/19/2011 04:30 PM, Simon Josefsson wrote: > >>>>> That's a nice question. This API is mostly interesting to people >>>>> who are porting gnutls to another crypto library. We might >>>> An API is an API, is an API. >>> Indeed but it doesn't have to be stable. That part was intended to >>> change often by design. >> I don't think that is wise in the long run -- if we want people to use >> the APIs they must be stable. If they aren't intended to be stable, it >> is better to mark them as private functions by prefixing them with >> _gnutls instead or similar. > > Indeed, but the API is already there. If we now add an underscore, then > we would break ABI... We could modify them in version 3 that breaks > the ABI anyway. Yes. Fortunately I don't think many projects have started using it since it is such a recent feature and it something that is rarely used. So we could mark it as deprecated in 2.12.0 and remove it for 3.0. /Simon From david.kirkby at onetel.net Mon Feb 21 22:55:23 2011 From: david.kirkby at onetel.net (David Kirkby) Date: Mon, 21 Feb 2011 21:55:23 +0000 Subject: support for AIX and HP-UX In-Reply-To: <871v31umqn.fsf@latte.josefsson.org> References: <1545624608.12790.1297951952441.JavaMail.apache@mail21.abv.bg> <4D5D5BAE.8000708@onetel.net> <4D5D9FAD.2090805@gnutls.org> <4D5E51EB.2030801@onetel.net> <87oc68hwzd.fsf@latte.josefsson.org> <4D6153C6.7030408@onetel.net> <871v31umqn.fsf@latte.josefsson.org> Message-ID: On 21 February 2011 21:00, Simon Josefsson wrote: > "Dr. David Kirkby" writes: >> Clearly a better solution would be to get this fixed properly. When I >> have some time, I'll build the latest source (or latest snapshot from >> where ???) and report if that builds or not. Perhaps we can get the >> full package to build on both AIX and HP-UX. My HP-UX system is not >> fully POSIX compliant, as the latest version which will run on my >> hardware is not POSIX. >> >> But my AIX 5.3 system is fully POSIX, but gnutls would not build on that either. > > I looked at your build log failures and it looks like getaddrinfo and/or > sockaddr_storage related problems -- chances are that recent gnulib has > fixed those problems. > Hopefully we'll get a release candidate out real soon so you can test > that. > > Thanks, > Simon > That sounds good. I don't follow this list a lot, so perhaps if someone is kind enough to drop me a mail and ask me to test on AIX and HP-UX I will do so. I can also provide access to the hardware for others too if needed. Dave From nmav at gnutls.org Mon Feb 21 23:43:40 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Feb 2011 23:43:40 +0100 Subject: ABI breakage in 2.10.4 --> 2.11.6? In-Reply-To: <87wrktt7z3.fsf@latte.josefsson.org> References: <20110217190009.GB2459@downhill.g.la> <4D5D9D89.50308@gnutls.org> <20110218171004.GA2462@downhill.g.la> <4D5F89F6.3040009@gnutls.org> <87wrkw4b5b.fsf@vigenere.g10code.de> <4D5F919B.90902@gnutls.org> <87k4gwhwjh.fsf@latte.josefsson.org> <4D601257.4040002@gnutls.org> <87wrktt7z3.fsf@latte.josefsson.org> Message-ID: <4D62EA9C.9020703@gnutls.org> On 02/21/2011 10:04 PM, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> On 02/19/2011 04:30 PM, Simon Josefsson wrote: >> >>>>>> That's a nice question. This API is mostly interesting to people >>>>>> who are porting gnutls to another crypto library. We might >>>>> An API is an API, is an API. >>>> Indeed but it doesn't have to be stable. That part was intended to >>>> change often by design. >>> I don't think that is wise in the long run -- if we want people to use >>> the APIs they must be stable. If they aren't intended to be stable, it >>> is better to mark them as private functions by prefixing them with >>> _gnutls instead or similar. >> >> Indeed, but the API is already there. If we now add an underscore, then >> we would break ABI... We could modify them in version 3 that breaks >> the ABI anyway. > > Yes. Fortunately I don't think many projects have started using it > since it is such a recent feature and it something that is rarely used. > So we could mark it as deprecated in 2.12.0 and remove it for 3.0. Yes. Internal APIs shouldn't have been exposed in the first place. regards, Nikos From wk at gnupg.org Tue Feb 22 16:42:23 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Feb 2011 16:42:23 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 21 Feb 2011 15:03:14 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> Message-ID: <87sjvg13fk.fsf@vigenere.g10code.de> On Mon, 21 Feb 2011 15:03, nmav at gnutls.org said: > I know... My main issues with libgcrypt are that I > got the impression that it is intended to be used > as a back-end of gnupg and other uses are not > considered or are considered as side-effects... That is definitely wrong. If that would be the case we would not have gone into the trouble of maintaining a general purpose library. > My main issues were: > * performance... gcrypt is very slow in the software > implementation of AES and SHA-1, comparing to Depends on your hardware. See my recent announcement. In fact we did some work on CFB and CBC performace to help GnuPG and gnutls more than 2 years ago. SHA-2 performance was recently also improved. Tuning of Libgcrypt is not not very complicated but it takes quite some time. Thus if I have to do it, I need to have a real use case. > other libraries and nettle... Moreover it uses its Please recall that Libgcrypt is a core GNU project and requires CAs. Thus it is not possible to use some of the better tuned implementations. Many years ago I discussed this with Brian Gladman: Although he then allows to use his code under the GPL, we was not able to sign a disclaimer of CA. Thus we have to do this work ourself. > own gmp that prevents from including all optimizations > added to the original gmp library. Let's not repeat this over and over again. In short: At the time the Libgcrypt code was written, tehre was no GMP development at all. Later GMP change the entire configuration system; which made it hard to re-use the asm code. > * mandates how the library is going to be used by > using setuid etc... Why shouldn't a setuid application Libgcrypt is about security and thus it uses secure defaults. The application is abale to chnage tehse defaults. > perform TLS? Indeed there are risks but it should be > the application developer to decide, not us. I disagree. Look at all the failures we have seen over last 20 years with crypto code; most of them are due to "let the application developer make sure it is used properly". Libgcrypt tries to minimize the risks. > * lack of low level functions to perform RSA/DSA/ECC. Please explain. > * gpg-error... adds a library dependence for something > that is really simple and could be part of libgcrypt > anyway. For non-gnupg applications there is nothing > to be gained by this shared library. Error management is not simple. In fact, gnutls should have adopted gpg-error as well. For example, gpg-error allows to figure out the subsystem which generated the error. This is often very useful. It is very easy to use and does not require many code changes as other error management systems do (look at GTK+). > Especially performance is a big issue in gnutls, since e.g. in > mod_gnutls we can have a server performing crypto with nettle > in 50% load, while with libgcrypt the server is on it's capacity > at 100% load. Those issues are better in libnettle. However How do you measure load? Why don't we discuss these things to find a solution? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Tue Feb 22 20:11:29 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 22 Feb 2011 20:11:29 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <4D617846.5090508@gnutls.org> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> <20110220190629.GE2038@downhill.g.la> <4D617846.5090508@gnutls.org> Message-ID: <20110222191129.GC2073@downhill.g.la> On 2011-02-20 Nikos Mavrogiannopoulos wrote: > On 02/20/2011 08:06 PM, Andreas Metzler wrote: [...] > > I started, but have given up for now since git is incompilable most of > > the time. (Really, out of a dozen git bisects there are 10 unbuildable > > checkouts.) > > > > The bug is absent in the last 2.9. release > > but present in 2.11.0. > > > > I will revisit when I have hours to spare again. Status update: eb3dc6ff292de8f40427e8ebb702aa7c2e5bdee8 bad. 9fd9ba397442fa0d593766e1ae396e589abf4c41 good. I have not yet found a version on HEAD in between that compiled. > Could you provide the output of the "resume -v"? It might help > locating the issue. see below. thanks, cu andreas try to resume from db server: ready. Listening to port '5556'. server |<2>| ASSERT: pkcs11.c:337 client |<2>| ASSERT: pkcs11.c:337 client |<2>| Cannot load /etc/gnutls/pkcs11.conf server |<2>| Cannot load /etc/gnutls/pkcs11.conf Launched, generating DH parameters... server: connection from 127.0.0.1, port 39272 client |<2>| EXT[0x40ecf8]: Sending extension CERT TYPE (3 bytes) client |<2>| EXT[0x40ecf8]: Sending extension SAFE RENEGOTIATION (1 bytes) client |<2>| EXT[0x40ecf8]: Sending extension SIGNATURE ALGORITHMS (12 bytes) server |<2>| ASSERT: gnutls_db.c:326 server |<2>| ASSERT: gnutls_db.c:246 server |<2>| EXT[0x415be8]: Found extension 'CERT TYPE/9' server |<2>| EXT[0x415be8]: Found extension 'SAFE RENEGOTIATION/65281' server |<2>| EXT[0x415be8]: Found extension 'SIGNATURE ALGORITHMS/13' server |<2>| EXT[0x415be8]: Found extension 'CERT TYPE/9' server |<2>| EXT[0x415be8]: Found extension 'SAFE RENEGOTIATION/65281' server |<2>| EXT[0x415be8]: Found extension 'SIGNATURE ALGORITHMS/13' server |<2>| EXT[0x415be8]: Found extension 'CERT TYPE/9' server |<2>| ASSERT: ext_cert_type.c:127 server |<2>| ASSERT: ext_cert_type.c:127 server |<2>| ASSERT: ext_cert_type.c:144 server |<2>| EXT[0x415be8]: Found extension 'SAFE RENEGOTIATION/65281' server |<2>| EXT[0x415be8]: Found extension 'SIGNATURE ALGORITHMS/13' server |<2>| EXT[0x415be8]: Sending extension SAFE RENEGOTIATION (1 bytes) client |<2>| EXT[0x40ecf8]: Found extension 'SAFE RENEGOTIATION/65281' client |<2>| ASSERT: ext_session_ticket.c:722 resume db storing... (32-492) client: Handshake was completed key: 43 14 b6 ec 47 70 a8 33 ff 00 7f 24 29 52 08 db a4 85 86 8e 5d 0d a0 b3 a1 00 6f 94 46 0f fd 74 data: 02 00 00 01 13 00 00 03 ff 00 00 00 81 00 b6 4c 70 da 39 6c 54 2b 2b 7c ba b1 ac df 88 ac 5f f7 5b cb d5 16 f0 f3 61 b2 e6 c6 2d 86 42 ff 6c fc f4 06 58 fd 5d f6 2d b6 3f 60 e9 ad f7 09 92 75 ad ec a8 42 23 54 9a 62 c7 8e 40 82 08 01 83 fb f0 27 f2 22 91 92 71 6f ef 4b c9 21 af 0d 2b 95 08 b2 78 2b d0 80 5d ce 19 e1 8e 13 2c 1c c3 ea 10 4f 84 a6 14 e0 fb 1f 4b 26 25 ed 82 37 28 d8 a5 ec 41 5d 0f c0 d2 66 d3 17 d4 0a 9b 57 00 00 00 01 05 00 00 00 81 00 97 b2 b4 bb a5 54 4a 84 3f ba 6d b1 5e eb 90 32 66 1b 6b ef 5e fe ff fb e2 89 2a f4 53 66 d5 90 f8 2f 29 b6 08 ae 22 ea d1 a8 4c 9b a1 81 8c 36 db 52 4e 6d 48 b5 1d 0b 8a 8b 63 1c 56 f7 40 f1 00 22 0a 74 2a ca e4 4b fb 9e ae 70 44 0a 12 2b 62 3b e6 72 75 0a 10 7d 10 cf bd b1 81 4f 55 ea d8 c4 bb 5c 08 61 b4 3c f9 87 61 3b 80 44 0e 85 04 3d b2 12 fd cf 92 c8 d9 5a 8e 7d f0 1b 0d df 00 00 00 ac 00 00 00 00 00 00 00 00 00 6c 00 00 23 13 31 53 47 06 5e 99 61 80 f0 fb b2 b4 b0 cd d2 91 4f 0f 4f f6 32 f8 24 52 a5 cb 15 7d 54 1c 51 58 e8 58 3d 5b c1 9c 0d 1f 04 dc 73 08 7f 78 4d 64 08 33 48 b2 16 02 81 2f c6 2b c3 58 98 ce 23 57 03 bd 14 a6 ea d5 b8 f0 84 65 24 20 70 5f 4d 64 08 33 3f 8c 1f f9 ac ca d5 de 01 97 81 37 a7 5d 46 0c 38 7a 08 f1 e4 e5 96 42 e6 9b a2 eb 00 00 00 20 00 00 40 00 00 00 40 00 43 14 b6 ec 47 70 a8 33 ff 00 7f 24 29 52 08 db a4 85 86 8e 5d 0d a0 b3 a1 00 6f 94 46 0f fd 74 4d 64 08 33 00 00 00 01 00 00 00 0d 00 00 00 18 00 00 00 05 00 00 00 01 00 00 00 02 00 00 00 06 00 00 00 07 00 00 00 08 server: Handshake was completed - Received 9 bytes: Hello TLS server: Peer has closed the GnuTLS connection server: connection from 127.0.0.1, port 39273 client |<2>| ASSERT: gnutls_handshake.c:1981 client |<2>| ASSERT: gnutls_handshake.c:2630 client: Handshake failed GnuTLS error: GnuTLS internal error. server |<2>| ASSERT: gnutls_buffers.c:634 server |<2>| ASSERT: gnutls_record.c:911 server |<2>| ASSERT: gnutls_handshake.c:2857 server: Handshake has failed (A TLS packet with unexpected length was received.) global stop try to resume from session ticket server: ready. Listening to port '5556'. From nmav at gnutls.org Tue Feb 22 21:56:46 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Feb 2011 21:56:46 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <20110222191129.GC2073@downhill.g.la> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> <20110220190629.GE2038@downhill.g.la> <4D617846.5090508@gnutls.org> <20110222191129.GC2073@downhill.g.la> Message-ID: <4D64230E.9020700@gnutls.org> On 02/22/2011 08:11 PM, Andreas Metzler wrote: > On 2011-02-20 Nikos Mavrogiannopoulos wrote: >> On 02/20/2011 08:06 PM, Andreas Metzler wrote: > [...] >>> I started, but have given up for now since git is incompilable most of >>> the time. (Really, out of a dozen git bisects there are 10 unbuildable >>> checkouts.) >>> >>> The bug is absent in the last 2.9. release >>> but present in 2.11.0. >>> >>> I will revisit when I have hours to spare again. > > Status update: > eb3dc6ff292de8f40427e8ebb702aa7c2e5bdee8 bad. > 9fd9ba397442fa0d593766e1ae396e589abf4c41 good. > I have not yet found a version on HEAD in between that compiled. Thank you. Does the commit below fix the issue? http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=1abe917781a83df1b362cd0192a2baff24979201 regards, Nikos From ludo at gnu.org Tue Feb 22 23:15:04 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 22 Feb 2011 23:15:04 +0100 Subject: Nettle integration issues Message-ID: <87zkpnaf87.fsf@gnu.org> Hello! In master (commit e3c98490a827a17782434587705be0ee8adaadd3), I have this problem: --8<---------------cut here---------------start------------->8--- $ nm .libs/libgnutls.so | grep nettle_sha256_update U nettle_sha256_update $ nm nettle/.libs/libcrypto.a | grep nettle_sha256_update U nettle_sha256_update --8<---------------cut here---------------end--------------->8--- This is cured for me by this patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 442 bytes Desc: not available URL: -------------- next part -------------- Indeed, $(NETTLE_LIBS) isn?t helpful here: --8<---------------cut here---------------start------------->8--- $ grep NETTLE_LIBS ../config.log NETTLE_LIBS='-lgmp -lpthread -lhogweed' --8<---------------cut here---------------end--------------->8--- What do you think? Thanks, Ludo?. From nmav at gnutls.org Wed Feb 23 11:17:46 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Feb 2011 11:17:46 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87sjvg13fk.fsf@vigenere.g10code.de> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> <87sjvg13fk.fsf@vigenere.g10code.de> Message-ID: On Tue, Feb 22, 2011 at 4:42 PM, Werner Koch wrote: >> My main issues were: >> * performance... gcrypt is very slow in the software >> implementation of AES and SHA-1, comparing to > Depends on your hardware. ?See my recent announcement. ?In fact we did > some work on CFB and CBC performace to help GnuPG and gnutls more than 2 > years ago. ?SHA-2 performance was recently also improved. My tests (march 2010) were with libgcrypt 1.4.4 and nettle 2.0 on a dual core amd64... Using the RSA (encryption)/AES-CBC/HMAC-SHA-1 ciphersuite of TLS. This is quite a popular ciphersuite of TLS because it is fast (comparing to diffie-hellman ones). The tests were performed using siege (running from another machine) and apache/mod_gnutls, running for 30 seconds. gnutls+libgcrypt: Response time: 0.23 secs Transaction rate: 63.88 trans/sec Throughput: 12.38 MB/sec gnutls+nettle: Response time: 0.11 secs Transaction rate: 131.63 trans/sec Throughput: 25.51 MB/sec The response time is actually the time spent on a handshake, and it seems that RSA decryption takes longer on libgcrypt than nettle. On an individual speed test I got: SHA1: nettle faster 20% AES-128-CBC: nettle faster 40% RC4: nettle faster 30% 3DES-CBC: gcrypt faster 10% SHA256: nettle faster 30% (this is probably no longer true since I used libgcrypt 1.4.4). > Tuning of Libgcrypt is not not very complicated but it takes quite some > time. ?Thus if I have to do it, I need to have a real use case. >> other libraries and nettle... Moreover it uses its > Please recall that Libgcrypt is a core GNU project and requires CAs. > Thus it is not possible to use some of the better tuned implementations. > Many years ago I discussed this with Brian Gladman: Although he then > allows to use his code under the GPL, we was not able to sign a > disclaimer of CA. ?Thus we have to do this work ourself. I know and pretty understand that, but it seems that here it is limiting us rather than allowing software re-use. I.e. if Niels or Brian have a faster AES under GPL why cannot we take advantage of that? Could we have a setup where one could choose to have an FSF copyrighted work or a combination of it? (I.e. at configure one selects whether the fsf version of the algorithms will be included or the optimized but by another copyright holders?). >> own gmp that prevents from including all optimizations >> added to the original gmp library. > Let's not repeat this over and over again. ?In short: At the time the > Libgcrypt code was written, tehre was no GMP development at all. ?Later > GMP change the entire configuration system; which made it hard to re-use > the asm code. I don't expect you to backport everything from the new gmplib, I don't even think it is a good idea. The good thing with having separate projects is that each one can optimize his part. I can work on optimizations on the TLS protocol, you can work on the algorithms, and the gmp guys on the big number arithmetic. For me there is no point in insisting in maintaining the old version of gmp. You could abolish the internal version for the actual gmplib, or even use another bignumber library, that delegates the optimizations to another project. >> * mandates how the library is going to be used by >> using setuid etc... Why shouldn't a setuid application > Libgcrypt is about security and thus it uses secure defaults. ?The > application is abale to chnage tehse defaults. >> perform TLS? Indeed there are risks but it should be >> the application developer to decide, not us. > I disagree. ?Look at all the failures we have seen over last 20 years > with crypto code; most of them are due to "let the application developer > make sure it is used properly". ?Libgcrypt tries to minimize the risks. But this issue is not about cryptography. A cryptographic library is about cryptography and not security in general. Security is decided by the application or by another security policy library. Libgcrypt is not such a library. It is a library that people don't even know they are using (the same is for gnutls). They want to do a secure connection somewhere, and they happen to use us. If they cannot use us, because we set specific policies for them, they'll use another library or fall-back to unsecure connections. They are not going to disable libgcrypt's policies because they might not even know that libgcrypt is being used (maybe they just do an ldap call or so). >> * lack of low level functions to perform RSA/DSA/ECC. > Please explain. [this is of lower importance that the other points] To do a DSA signature with libgcrypt it requires: gcry_sexp_build("(private-key(dsa(p%m)(q%m)(g%m)(y%m)(x%m)))",...) gcry_sexp_build("%m",...) //for the hash gcry_pk_sign() gcry_sexp_find_token("r"...) gcry_sexp_nth_mpi() // get r gcry_sexp_find_token("s"...) gcry_sexp_nth_mpi() // get s gcry_sexp_release(...) with nettle I only need to use: _dsa_sign(...) Given that anyway there is no interface that can cope with all public key algorithms in uniform (sexp doesn't either), having access to the low-level public key algorithms is more efficient. >> * gpg-error... adds a library dependence for something >> that is really simple and could be part of libgcrypt >> anyway. For non-gnupg applications there is nothing >> to be gained by this shared library. > Error management is not simple. ?In fact, gnutls should have adopted > gpg-error as well. ?For example, gpg-error allows to figure out the > subsystem which generated the error. ?This is often very useful. ?It is > very easy to use and does not require many code changes as other error > management systems do (look at GTK+). I'll check it but gnutls has its own error subsystem. Detecting the subsystem that caused the error, is not so important for gnutls since we only have one. What is important is logging and auditing something that we currently do with a logging callback, but will try to improve in order to have auditing fascilities as well (i.e. to know that in this connection from that IP illegal or replayed packets were received in DTLS etc.). regards, Nikos From wk at gnupg.org Wed Feb 23 16:03:24 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Feb 2011 16:03:24 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 23 Feb 2011 11:17:46 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> <87sjvg13fk.fsf@vigenere.g10code.de> Message-ID: <87sjveztc3.fsf@vigenere.g10code.de> On Wed, 23 Feb 2011 11:17, nmav at gnutls.org said: > Using the RSA (encryption)/AES-CBC/HMAC-SHA-1 ciphersuite of TLS. This is How do you handle the random requirements - has the RNG been seeded prior to the tests? Does Nettle use blinding? > On an individual speed test I got: > SHA1: nettle faster 20% How do yo use it? gcry_md_hash_buffer, or gcry_md_open, write, close? > AES-128-CBC: nettle faster 40% There is definitley room for improvements. > RC4: nettle faster 30% Come one, no sane cryptographer will use arcfour. > rather than allowing software re-use. I.e. if Niels or Brian have a > faster AES under > GPL why cannot we take advantage of that? Could we have a setup where > one could choose to have an FSF copyrighted work or a combination We need to keep Libgcrypt legally safe. Thus there we don't want to change that. Giving a choice of code variants will lead to high maintenance costs and makes the code more complex and thus buggy. > could abolish the internal version for the actual gmplib, or even use > another bignumber library, that delegates the optimizations to another > project. There is no internal version libgmp. The MPI code in Libgcrypt is very different from GMP. Only the asm code was pretty similar. And right, it is somewhat slower to help protect confidential data. > But this issue is not about cryptography. A cryptographic library is > about cryptography and not security in general. Security is decided by > the application or by another security policy library. Libgcrypt is Nope. You can't build security into a system if you don't start implementing it in the foundation. Thus is is not alone an application issue. > They are not going to disable libgcrypt's policies because they might > not even know that libgcrypt is being used (maybe they just do an ldap > call or so). Building a security system without knowing what's going on in all parts of the system is a major engineering mistake. I can't repeat it often enough: A library is just a collection of code which makes things easier. It does not relieve you from knowing how to use this code properly. > Given that anyway there is no interface that can cope with > all public key algorithms in uniform (sexp doesn't either), having Right. However, using s-expressions is quite flexible and allows its use all over the place. No more need to take care of all the nitty gritty details of key parameters. Only the protocol engine needs to convert them - this conversions needs to be done anyway. > access to the low-level public key algorithms is more efficient. Sure low-level might is more efficient but only if you go into the trouble to add the high-level code your self. You will need it anyway for solid engineering principles. > I'll check it but gnutls has its own error subsystem. Detecting > the subsystem that caused the error, is not so important for > gnutls since we only have one. What is important is logging Thus you need to check all error codes form the subsystem and translate them to gnutls error codes. With a location as part of the error code, it would be easy to see that for example not a certain curve is not implemented or a low-level selftest has failed. Anyway, for gnutls is is not possible to use gpg-error due to ABI and API incompatibilities. I noted that merely to make clear that gpg-error may be used by other projects. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Wed Feb 23 18:14:13 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Feb 2011 18:14:13 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87sjveztc3.fsf@vigenere.g10code.de> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> <87sjvg13fk.fsf@vigenere.g10code.de> <87sjveztc3.fsf@vigenere.g10code.de> Message-ID: On Wed, Feb 23, 2011 at 4:03 PM, Werner Koch wrote: >> Using the RSA (encryption)/AES-CBC/HMAC-SHA-1 ciphersuite of TLS. This is > How do you handle the random requirements - has the RNG been seeded > prior to the tests? ?Does Nettle use blinding? The RNG has been seeded using /dev/urandom in both cases. Nettle uses yarrow as an RNG, and the locking is done on the gnutls level. The gnutls code that uses nettle RSA does RSA blinding. >> On an individual speed test I got: >> SHA1: nettle faster 20% > How do yo use it? ?gcry_md_hash_buffer, or gcry_md_open, write, close? open/write/close... >> RC4: nettle faster 30% > Come one, no sane cryptographer will use arcfour. RC4 is used in TLS. >> They are not going to disable libgcrypt's policies because they might >> not even know that libgcrypt is being used (maybe they just do an ldap >> call or so). > Building a security system without knowing what's going on in all parts > of the system is a major engineering mistake. ?I can't repeat it often > enough: A library is just a collection of code which makes things > easier. ?It does not relieve you from knowing how to use this code > properly. I disagree on that. When designing a system, you design the architecture on the high level and you don't care about the implementation. You may have a crypto component, but you don't care if this is libgcrypt, libcrypto, or libtomcrypt. It's just a component of your design. If libgcrypt wants to enforce policies in my design, I replace it with a component that follows the policies I set. If my design consists of: * an http client * an http library that does HTTPS and compression * a TLS library * a crypto library * a compression library You don't want the http client to even know it is using that crypto or compression library. It shouldn't care. regards, Nikos From nmav at gnutls.org Wed Feb 23 18:40:32 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Feb 2011 18:40:32 +0100 Subject: Nettle integration issues In-Reply-To: <87zkpnaf87.fsf@gnu.org> References: <87zkpnaf87.fsf@gnu.org> Message-ID: <4D654690.4010709@gnutls.org> On 02/22/2011 11:15 PM, Ludovic Court?s wrote: > Hello! > > In master (commit e3c98490a827a17782434587705be0ee8adaadd3), I have this > problem: > --8<---------------cut here---------------start------------->8--- > $ nm .libs/libgnutls.so | grep nettle_sha256_update > U nettle_sha256_update > > $ nm nettle/.libs/libcrypto.a | grep nettle_sha256_update > U nettle_sha256_update > --8<---------------cut here---------------end--------------->8--- > > This is cured for me by this patch: Does the gnutls2_12_x branch work for you in that matter? From nmav at gnutls.org Wed Feb 23 19:19:07 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Feb 2011 19:19:07 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: <87sjveztc3.fsf@vigenere.g10code.de> References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> <87sjvg13fk.fsf@vigenere.g10code.de> <87sjveztc3.fsf@vigenere.g10code.de> Message-ID: <4D654F9B.60007@gnutls.org> On 02/23/2011 04:03 PM, Werner Koch wrote: > Building a security system without knowing what's going on in all parts > of the system is a major engineering mistake. I can't repeat it often > enough: A library is just a collection of code which makes things > easier. It does not relieve you from knowing how to use this code > properly. In any case, these are personal opinions and we can agree that we disagree. However limiting the library users to the ones that agree with a single view, will just reduce the user-base (unless they don't have a choice - and in that case there is). regards, Nikos From ametzler at downhill.at.eu.org Wed Feb 23 19:30:02 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 23 Feb 2011 19:30:02 +0100 Subject: 2.11.6 resume test fails on powerpc s390 and sparc In-Reply-To: <4D64230E.9020700@gnutls.org> References: <20110220083508.GA2038@downhill.g.la> <4D61315E.9040600@gnutls.org> <20110220190629.GE2038@downhill.g.la> <4D617846.5090508@gnutls.org> <20110222191129.GC2073@downhill.g.la> <4D64230E.9020700@gnutls.org> Message-ID: <20110223183002.GC2162@downhill.g.la> On 2011-02-22 Nikos Mavrogiannopoulos wrote: [...] > Thank you. Does the commit below fix the issue? > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=1abe917781a83df1b362cd0192a2baff24979201 [...] A test build on s390 worked. I have just uploaded patched sources to get testbuilds on the other failing archs. 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 Wed Feb 23 21:18:03 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Feb 2011 21:18:03 +0100 Subject: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 23 Feb 2011 18:14:13 +0100") References: <87k4gvgjx4.fsf@latte.josefsson.org> <20110220102337.GC2038@downhill.g.la> <4D612F67.6080909@gnutls.org> <87ei714jaa.fsf@vigenere.g10code.de> <87sjvg13fk.fsf@vigenere.g10code.de> <87sjveztc3.fsf@vigenere.g10code.de> Message-ID: <87fwrezero.fsf@vigenere.g10code.de> On Wed, 23 Feb 2011 18:14, nmav at gnutls.org said: > You don't want the http client to even know it is using that crypto or > compression library. It shouldn't care. Fine with me. To implement that more correctly you need to use another process. Simply using code from a library does not solve this problem. An ELF DSO is not different than linking the code statically. On Windows a DLL is a little bit different (because it is a kernel object) but in the end is does not matter either; your code may change the behaviour of the library and in the worst case the library stops working. With separate processes the story is a bit different: The kernel knows about the processes and tries very hard to isolate them. All what we do with libs is just a naive try to mimic what a kernel is able to do. You better don't think of application and library as separate objects but of writing one of these old PCDOS programs (which may include TSRs and driver) with no kernel guaranteed protection boundaries. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From home_pw at msn.com Sat Feb 26 20:53:01 2011 From: home_pw at msn.com (peter williams) Date: Sat, 26 Feb 2011 11:53:01 -0800 Subject: certtool and SAN URI population Message-ID: I'm considering altering file in certtool(1) implementation files so it is easy in the "template" configuration file to specify a value for the "SAN URI" fields of SSL client certs. It's already easy to specify an SAN domain-name field via the template. If I do it, would someone consider the code changes for inclusion in the package? The changes are in support of an W3C incubator project applying client SSL certs which have a URI as name form. Can anyone think of a way to use the template file to include a SAN URI field in a SSL client cert, using the current release of certtool(1)? (Perhaps, there is a syntax for adding an arbitrary extension value, expressed in hex, perhaps). Here is what I want the gnutls test site to do when showing a SAN URI. This was done using someone's cert minting web site to create/manage the SSL client cert, rather than using certtool(1). This is GNUTLS Session ID: 02000000F4FFE0B7B67C08080400000000000000C60100001000000002000000 If your browser supports session resuming, then you should see the same session ID, when you press the reload button. Server Name: test.gnutls.org Ephemeral DH using prime of 1024 bits. Protocol version: TLS1.1 Certificate Type: X.509 Key Exchange: DHE-RSA Compression NULL Cipher AES-256-CBC MAC SHA1 Ciphersuite DHE_RSA_AES_256_CBC_SHA1 X.509 Certificate Information: Version: 3 Serial Number (hex): 4b45d7295406364afe32d209942be329 Issuer: O=FOAF\+SSL,OU=The Community of Self Signers,CN=Not a Certification Authority Validity: Not Before: Sat Feb 26 16:49:18 UTC 2011 Not After: Fri Feb 17 18:49:18 UTC 2012 Subject: O=FOAF\+SSL,OU=The Community Of Self Signers,UID=http://webid.myxwiki.org/xwiki/bin/view/XWiki/homepw4#me,CN=home pw4 Subject Public Key Algorithm: RSA Modulus (bits 1536): b5:20:f3:84:79:f5:80:3a:7a:b3:32:33:15:5e:ee:f8 ad:4e:1f:57:5b:60:3f:77:80:f3:f6:0c:ea:b1:34:61 8f:be:11:75:39:10:9c:01:5c:5f:95:9b:49:7e:67:c1 a3:b2:c9:6e:5f:09:8b:b0:bf:2a:65:97:77:9d:26:f5 5f:e8:d3:20:de:7a:f0:56:2f:d2:cd:06:7d:bc:9d:77 5b:22:fc:06:e6:34:22:71:7d:00:a6:80:1d:ed:af:d7 b5:4a:93:c3:f4:e5:95:38:47:56:73:97:2e:52:4f:4e c2:a3:66:7d:0e:1a:c8:56:d5:32:e3:2b:f3:0c:ef:8c 1a:dc:41:71:89:20:56:8f:be:9f:79:3d:ae:ea:ee:aa 7e:83:67:b7:22:8a:89:5a:6c:f9:45:45:a6:f6:28:66 93:27:7a:1b:c7:75:04:25:ce:6c:35:d5:70:e8:94:53 11:7b:88:ce:24:20:6a:fd:21:6a:70:5a:d0:8b:7c:59 Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Usage (critical): Digital signature. Non repudiation. Key encipherment. Key agreement. Certificate signing. Unknown extension 2.16.840.1.113730.1.1 (not critical): ASCII: .... Hexdump: 030205a0 Subject Key Identifier (not critical): 27273521ca35671123bb281c46903fc2f43051c0 Subject Alternative Name (critical): URI: http://webid.myxwiki.org/xwiki/bin/view/XWiki/homepw4#me Signature Algorithm: RSA-SHA Signature: c8:22:58:c6:e9:46:af:9f:41:6f:82:3f:2d:25:ed:69 ca:6e:43:f4:89:2f:24:c7:96:1d:97:8e:09:13:1e:ac 32:c6:f0:ba:df:79:19:d3:56:28:6a:ee:ea:42:e6:a8 2e:f1:b4:2e:0d:45:7c:6d:dd:7d:bc:a6:7e:12:aa:0f 5b:c2:cb:36:f5:dd:c6:ec:2b:e0:eb:55:15:e0:fa:8a 9c:e4:3a:b7:ee:c2:89:bd:7b:ca:9e:fe:0a:98:b5:36 dd:12:ca:68:66:4b:9f:c2:3e:c3:58:51:1c:d5:84:7f aa:07:3f:14:27:a1:d7:5b:41:ab:f7:d8:64:5c:58:64 Other Information: MD5 fingerprint: cd3af2ec77b2421229ea61a88d3a181a SHA-1 fingerprint: 1ee2e509ed8d61251ee10b7078ae9202129b3f76 Public Key Id: 6a651cf7e0a7f791ba8f29ebb201822e354b49f6 Your HTTP header was: User-Agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.7.62 Version/11.01 Host: test.gnutls.org:5556 Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: en-US,en;q=0.9 Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Referer: http://www.gnu.org/software/gnutls/server.html Connection: Keep-Alive -------------- next part -------------- An HTML attachment was scrubbed... URL: From home_pw at msn.com Sat Feb 26 21:28:20 2011 From: home_pw at msn.com (peter williams) Date: Sat, 26 Feb 2011 12:28:20 -0800 Subject: certtool and SAN URI population In-Reply-To: References: Message-ID: Couple more questions, to help me focus writing code: In the output of the current gnutls test site, it shows "server name". Is this the ClientHello SNI field? Another way of asking this is: does the library's API design aim to give the normal API consumer access to the various ClientHello extensions (including SNI)? From: gnutls-devel-bounces+home_pw=msn.com at gnu.org [mailto:gnutls-devel-bounces+home_pw=msn.com at gnu.org] On Behalf Of peter williams Sent: Saturday, February 26, 2011 11:53 AM To: gnutls-devel at gnu.org This is GNUTLS Session ID: 02000000F4FFE0B7B67C08080400000000000000C60100001000000002000000 If your browser supports session resuming, then you should see the same session ID, when you press the reload button. Server Name: test.gnutls.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludo at gnu.org Sun Feb 27 19:59:16 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 27 Feb 2011 19:59:16 +0100 Subject: Priority strings Message-ID: <87tyfp9ud7.fsf@gnu.org> Hello! I updated the Guile bindings in ?master? to wrap ?gnutls_priority_set_direct? and deprecate the old method. However, could someone help me convert the test cases to use priority strings? For instance, ?anonymous-auth.scm? uses these priorities, after a ?gnutls_set_default_priority?: (define %protos (list protocol/tls-1.0)) (define %certs '()) (define %ciphers (list cipher/null cipher/arcfour cipher/aes-128-cbc cipher/aes-256-cbc)) (define %kx (list kx/anon-dh)) (define %macs (list mac/sha1 mac/rmd160 mac/md5)) What would be the corresponding priority string? Besides, while the old method was more verbose, it allowed programming errors to be spotted more easily (in the Guile bindings, you would get a type error if trying to use a MAC name when setting the cipher priority, for instance.) Could it coexist alongside priority strings? Thanks, Ludo?. From nmav at gnutls.org Sun Feb 27 23:59:01 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 27 Feb 2011 23:59:01 +0100 Subject: Priority strings In-Reply-To: <87tyfp9ud7.fsf@gnu.org> References: <87tyfp9ud7.fsf@gnu.org> Message-ID: <4D6AD735.9070500@gnutls.org> On 02/27/2011 07:59 PM, Ludovic Court?s wrote: > Hello! > > I updated the Guile bindings in ?master? to wrap > ?gnutls_priority_set_direct? and deprecate the old method. > > However, could someone help me convert the test cases to use priority > strings? > > For instance, ?anonymous-auth.scm? uses these priorities, after a > ?gnutls_set_default_priority?: > > (define %protos (list protocol/tls-1.0)) (define %certs '()) > (define %ciphers (list cipher/null cipher/arcfour cipher/aes-128-cbc > cipher/aes-256-cbc)) (define %kx (list kx/anon-dh)) (define > %macs (list mac/sha1 mac/rmd160 mac/md5)) > > What would be the corresponding priority string? You could use something like that: NONE:+VERS-TLS-ALL:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+ANON-DH To enable anonymous DH and the defaults for the others. If you want to explicitly specify AES, replace +CIPHER-ALL with +AES-128-CBC etc. > Besides, while the old method was more verbose, it allowed > programming errors to be spotted more easily (in the Guile bindings, > you would get a type error if trying to use a MAC name when setting > the cipher priority, for instance.) Could it coexist alongside > priority strings? No the old priority functions will be marked as deprecated and may be removed. I cannot understand though how the error you describe apply to that interface. If there is a typo or so, it will be returned by the set_direct function. regards, Nikos From simon at josefsson.org Mon Feb 28 14:06:11 2011 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Feb 2011 14:06:11 +0100 Subject: GnuTLS 2.10.5 released Message-ID: <871v2sb96k.fsf@latte.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.10.5. GnuTLS is a modern C library that implements 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 GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnu.org/software/gnutls/ What's New ========== ** libgnutls: Corrected verification of finished messages. ** libgnutls: Corrected signature generation and verification in the Certificate Verify message when in TLS 1.2. Reported by Todd A. Ouska. ** pkg-config gnutls.pc improvements. The file uses 'Requires.private' for libtasn1 and libz when needed, instead of Libs.private. From Andreas Metzler. ** 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 (7.0MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5.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.10.5.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: 2011-03-30] 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: 2011-03-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: 4530657082a0e754356de89a5529d1ad7a18e777 gnutls-2.10.5.tar.bz2 546e8631b68358cb495fcd6fd13274ba5a7370ef3848a459172d4370 gnutls-2.10.5.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: HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf 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.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 uses libgpg-error v1.8, libgcrypt v1.4.6, and GnuTLS v2.10.5. The Windows binary installer: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5-x86.exe (16MB) ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5-x86.exe.sig (OpenPGP) The checksum values for SHA-1 and SHA-224 are: 85bed4c33f50941f62560275a485c942dd7e5645 gnutls-2.10.5-x86.exe 915c7b1fb53b8a4f22fcd526c0ccb8ea021709040d180f61b9914fc4 gnutls-2.10.5-x86.exe A ZIP archive containing the Windows binaries: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5-x86.zip (5.8MB) ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.5-x86.zip.sig (OpenPGP) A Debian mingw32 package is also available: ftp://ftp.gnu.org/gnu/gnutls/mingw32-gnutls_2.10.5-1_all.deb (5.3MB) The checksum values for SHA-1 and SHA-224 are: 73ee95cf76f2fcfc04fc44c3750776cbac53fe29 mingw32-gnutls_2.10.5-1_all.deb 7463ab8a17cee7bd0e8ab70b977868e7f577829bf5221c18c8f86f6a mingw32-gnutls_2.10.5-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Italian, Malay, Polish, Simplified Chinese, 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 AB, 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: 424 bytes Desc: not available URL: From INVALID.NOREPLY at gnu.org Mon Feb 28 20:07:23 2011 From: INVALID.NOREPLY at gnu.org (Andreas Metzler) Date: Mon, 28 Feb 2011 19:07:23 +0000 Subject: [sr #107608] duplicate entries in symbol script Message-ID: <20110228-200723.sv20807.51809@savannah.gnu.org> URL: Summary: duplicate entries in symbol script Project: GnuTLS Submitted by: ametzler Submitted on: Mo 28 Feb 2011 20:07:23 CET Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Quoting lib/libgnutls.map from 2.10.5: ------------------------- GNUTLS_2_8 { global: [...] gnutls_session_ticket_key_generate; gnutls_session_ticket_enable_client; gnutls_session_ticket_enable_server; } GNUTLS_1_4; GNUTLS_2_10 { global: gnutls_session_ticket_key_generate; gnutls_session_ticket_enable_client; gnutls_session_ticket_enable_server; [...] -------------------------- Note how the three symbols are listed in both GNUTLS_2_8 and GNUTLS_2_10 sections. Only one of the entries is actually used, GNU binutils (both ld and gold) use the first match, as can be seen in the final binaries: ametzler at argenau:/tmp/GNUTLS/gnutls.git$ objdump -T /tmp/GNUTLS/libgnutls26_2.10.5-1/usr/lib/libgnutls.so.26.16.14 | grep -E 'gnutls_session_ticket_enable_client|gnutls_session_ticket_enable_server|gnutls_session_ticket_key_generate' 00046310 g DF .text 0000006a GNUTLS_2_8 gnutls_session_ticket_enable_client 00046f80 g DF .text 00000102 GNUTLS_2_8 gnutls_session_ticket_key_generate 00046e80 g DF .text 000000f6 GNUTLS_2_8 gnutls_session_ticket_enable_server gold actually warns about this error: /usr/bin/ld: warning: using 'GNUTLS_2_8' as version for '|gnutls_session_ticket_enable_client' which is also named in version 'GNUTLS_2_10' in script /usr/bin/ld: warning: using 'GNUTLS_2_8' as version for 'gnutls_session_ticket_enable_server' which is also named in version 'GNUTLS_2_10' in script /usr/bin/ld: warning: using 'GNUTLS_2_8' as version for 'gnutls_session_ticket_key_generate' which is also named in version 'GNUTLS_2_10 Trivial patch for remotes/origin/gnutls_2_10_x attached. The issue is also present in HEAD. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Mo 28 Feb 2011 20:07:23 CET Name: 0001-fix-duplicate-symbols-in-version-script.patch Size: 904B By: ametzler bugfix _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/