From tim.kosse at filezilla-project.org Mon Oct 8 01:55:58 2007 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Mon, 08 Oct 2007 01:55:58 +0200 Subject: [gnutls-dev] Certificate with get_issuer_dn and get_dn failing with ASN1 parser: Error in TAG In-Reply-To: <87wsvzlh5k.fsf@mocca.josefsson.org> References: <87y7gjppuw.fsf@mocca.josefsson.org> <9e0cf0bf0708100512v1227820bk20d49c64e3a75d2@mail.gmail.com> <87hcn7pkdf.fsf@mocca.josefsson.org> <9e0cf0bf0708100725x5708add1i3b8d38afe82848ae@mail.gmail.com> <878x8ifcny.fsf@mocca.josefsson.org> <9e0cf0bf0708112213q4d297030jfa6c73cdd9a88f2c@mail.gmail.com> <87643lt7pl.fsf@mocca.josefsson.org> <9e0cf0bf0708121040s4382213ay91d5093192e265e0@mail.gmail.com> <87643jofum.fsf@mocca.josefsson.org> <87wsvzlh5k.fsf@mocca.josefsson.org> Message-ID: <4709720E.7030007@filezilla-project.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've encountered a certificate which cannot be parsed correctly with GnuTLS 2.0.1 Using certtool -i on the attached certificate prints the following two error messages: error: get_issuer_dn: ASN1 parser: Error in TAG error: get_dn: ASN1 parser: Error in TAG. OpenSSL however can parse the certificate without problems. Regards, Tim Kosse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCXIO8N9+lcqiUkURAv0/AJ9kP3b0Xa0HMPhZGtsomeL7F2AxmwCfQl9l mztupcNgweaq7UB7gtDoPAc= =JIdU -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testcertificate Url: /pipermail/attachments/20071008/bfd0ecde/attachment.pot -------------- next part -------------- A non-text attachment was scrubbed... Name: testcertificate.sig Type: application/octet-stream Size: 65 bytes Desc: not available Url : /pipermail/attachments/20071008/bfd0ecde/attachment-0001.obj From nmav at gnutls.org Mon Oct 8 11:07:35 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Oct 2007 12:07:35 +0300 Subject: [gnutls-dev] Certificate with get_issuer_dn and get_dn failing with ASN1 parser: Error in TAG In-Reply-To: <4709720E.7030007@filezilla-project.org> References: <87y7gjppuw.fsf@mocca.josefsson.org> <87wsvzlh5k.fsf@mocca.josefsson.org> <4709720E.7030007@filezilla-project.org> Message-ID: <200710081207.36160.nmav@gnutls.org> On Monday 08 October 2007, Tim Kosse wrote: > Hi, > I've encountered a certificate which cannot be parsed correctly with > GnuTLS 2.0.1 > Using certtool -i on the attached certificate prints the following two > error messages: > error: get_issuer_dn: ASN1 parser: Error in TAG > error: get_dn: ASN1 parser: Error in TAG. Indeed, there is an error in the TAG of this value (Pkcs9email). Your certificate contains a Printable string instead of the (correct) IA5String. openssl seems to ignore this error but we don't :) Which program did it generate the certificate? (pkcs9email is deprecated anyway). I will update the parser to display the value in hex if it had problems to decode it. regards, Nikos From ludo at gnu.org Mon Oct 8 22:57:34 2007 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 08 Oct 2007 22:57:34 +0200 Subject: [gnutls-dev] Recent SRP changes and Guile breakage Message-ID: <87sl4l8gu9.fsf@chbouib.org> Hi, Commit 1f24725c9a0b09e7a42ee18f2bb4c0fbac581b8f removed `GNUTLS_A_UNKNOWN_SRP_USERNAME' and `GNUTLS_A_MISSING_SRP_USERNAME', thereby breaking the Guile bindings. I just committed a tiny patch that fixes it. http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2518a0dc871d877bf3269cda498ae1831ff22fb8 Thanks, Ludovic. From simon at josefsson.org Tue Oct 9 16:59:12 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Oct 2007 16:59:12 +0200 Subject: [gnutls-dev] Recent SRP changes and Guile breakage In-Reply-To: <87sl4l8gu9.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?= =?iso-8859-1?Q?=E8s=22's?= message of "Mon, 08 Oct 2007 22:57:34 +0200") References: <87sl4l8gu9.fsf@chbouib.org> Message-ID: <87lkac8hbz.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi, > > Commit 1f24725c9a0b09e7a42ee18f2bb4c0fbac581b8f removed > `GNUTLS_A_UNKNOWN_SRP_USERNAME' and `GNUTLS_A_MISSING_SRP_USERNAME', > thereby breaking the Guile bindings. > > I just committed a tiny patch that fixes it. > > http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2518a0dc871d877bf3269cda498ae1831ff22fb8 Thanks. We are still discussing how the API/ABI break should be handled. But generally the change is to align with IANA's TLS alert registry. /Simon From gtefjknerfd at stobor.net Fri Oct 12 09:16:59 2007 From: gtefjknerfd at stobor.net (Mr Allwyn Fernandes) Date: Fri, 12 Oct 2007 17:16:59 +1000 Subject: [gnutls-dev] [PATCH] Load DH Params from File Message-ID: <200710121717.00092.gtefjknerfd@stobor.net> Hi, (Apologies if anyone gets this multiple times: I've tried sending it several times, and keep getting bounce messages... I don't see it in any of the archives so I _suspect_ it hasn't gotten through to anyone, but I'm not sure.) I recently added GnuTLS support to an app, and noticed a slight inconsistancy in the api; one can load certificates, keys and CRLs directly from a file, but there is no corresponding function which takes a filename and loads the DH params from the file. I'm using Debian Testing, which has gnutls13-1.7.19, but I noted that the current online documentation doesn't list a new method to do this either. I have created a trivial patch which implements an api function "gnutls_dh_params_import_pkcs3_file" from a combination of "gnutls_dh_params_import_pkcs3" and "gnutls_certificate_set_x509_crl_file" I have generated the patch against Debian's gnutls13-1.7.19 source, but appears to apply reasonably to the 2.0.1 source... Otherwise, for easy cut-n-paste, the new method is listed below, along with the corresponding header entry. If there are any comments or questions, please feel free to let me know. Cheers, Allwyn. In lib/gnutls_dh_primes.c, under gnutls_dh_params_import_pkcs3: /** * gnutls_dh_params_import_pkcs3_file - This function will import DH params * from a file containing a pkcs3 structure * @params: A structure where the parameters will be copied to * @pkcs3_file: should contain a PKCS3 DHParams structure PEM or DER encoded * @format: the format of params. PEM or DER. * * This function will extract the DHParams found in a file containing a PKCS3 * formatted structure. This is the format generated by "openssl dhparam" tool. * * If the structure is PEM encoded, it should have a header * of "BEGIN DH PARAMETERS". * * In case of failure a negative value will be returned, and * 0 on success. * **/ int gnutls_dh_params_import_pkcs3_file (gnutls_dh_params_t params, const char * pkcs3_file, gnutls_x509_crt_fmt_t format) { int ret; size_t size; char *data = read_binary_file (pkcs3_file, &size); if (data == NULL) { gnutls_assert (); return GNUTLS_E_FILE_ERROR; } ret = gnutls_dh_params_import_pkcs3 (params, data, format); free (data); if (ret < 0) { gnutls_assert (); return ret; } return ret; } In includes/gnutls/gnutls.h.in, under gnutls_dh_params_import_pkcs3: int gnutls_dh_params_import_pkcs3_file (gnutls_dh_params_t params, const char * pkcs3_file, gnutls_x509_crt_fmt_t format); And something like this for the NEWS file. ** API and ABI modifications: New API to load Diffie-Hellman parameters from file: gnutls_dh_params_import_pkcs3_file -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls13-1.7.19-dhfile.diff.gz Type: application/x-gzip Size: 1173 bytes Desc: not available Url : /pipermail/attachments/20071012/dff623e7/attachment.bin From n.mavrogiannopoulos at gmail.com Fri Oct 12 22:28:11 2007 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 12 Oct 2007 23:28:11 +0300 Subject: [gnutls-dev] 256 bit ciphers Message-ID: <200710122328.11634.n.mavrogiannopoulos@gmail.com> Hello, I think the 256 ciphers offer no more in security than their 128 bit equivalents and they are in general slower. Thus I think it would be a good idea to remove them from the default priority lists. Are there any objections or good reason to keep them? regards, Nikos From simon at josefsson.org Sat Oct 13 21:53:02 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 13 Oct 2007 21:53:02 +0200 Subject: [gnutls-dev] 256 bit ciphers In-Reply-To: <200710122328.11634.n.mavrogiannopoulos@gmail.com> (Nikos Mavrogiannopoulos's message of "Fri, 12 Oct 2007 23:28:11 +0300") References: <200710122328.11634.n.mavrogiannopoulos@gmail.com> Message-ID: <877ilqu6zl.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Hello, > I think the 256 ciphers offer no more in security than their 128 bit > equivalents and they are in general slower. Thus I think it would be a good > idea to remove them from the default priority lists. Are there any objections > or good reason to keep them? The gnutls_set_default_export_priority function is the same both for clients and servers, and while it may make sense to only use 128 bits by default in clients, not supporting 256 bits in servers seems problematic. What if a client supports AES-256 and ARCFOUR-128 connects to a GnuTLS server with default settings? Then they would end up with ARCFOUR-128 which seems bad. There should probably had been two "default" functions, one for clients and one for servers, since the defaults may be different. It may be too late to change that. Btw, it is difficult for applications to use the default GnuTLS plus some minor change. I mean, if an application wants to use the defaults plus AES-256, he must copy the entire cipher list from GnuTLS and add it back using gnutls_cipher_set_priority. OpenSSL have these ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH strings (see 'man ciphers') but I'm not sure it is a good idea. /Simon From simon at josefsson.org Sat Oct 13 21:58:20 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 13 Oct 2007 21:58:20 +0200 Subject: [gnutls-dev] 256 bit ciphers In-Reply-To: <200710122328.11634.n.mavrogiannopoulos@gmail.com> (Nikos Mavrogiannopoulos's message of "Fri, 12 Oct 2007 23:28:11 +0300") References: <200710122328.11634.n.mavrogiannopoulos@gmail.com> Message-ID: <873aweu6qr.fsf@mocca.josefsson.org> Also, I have a vague memory of people who believe that block ciphers with X bit keys only provide X/2 bits of security. I can't site papers now, but maybe you or someone else can substantiate or refute this. I've always thought that this was the reason AES were standardized with both 128 and 256 bit sizes. /Simon From simon at josefsson.org Sun Oct 14 19:57:15 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 14 Oct 2007 19:57:15 +0200 Subject: [gnutls-dev] GnuTLS 2.1.2 Message-ID: <87hcktmves.fsf@mocca.josefsson.org> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available Url : /pipermail/attachments/20071014/3d1f249e/attachment.pgp From simon at josefsson.org Sun Oct 14 20:23:02 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 14 Oct 2007 20:23:02 +0200 Subject: [gnutls-dev] GnuTLS 2.1.2 In-Reply-To: <396556a20710141106l2c50fa0nc2d4f8a3372fde3d@mail.gmail.com> (Adam Langley's message of "Sun, 14 Oct 2007 11:06:14 -0700") References: <87hcktmves.fsf@mocca.josefsson.org> <396556a20710141106l2c50fa0nc2d4f8a3372fde3d@mail.gmail.com> Message-ID: <87bqb1mu7t.fsf@mocca.josefsson.org> "Adam Langley" writes: > On 10/14/07, Simon Josefsson wrote: >> ** Added support for DSA2 using libgcrypt 1.3.0. > > Googling is failing to enlighten me on this point - what's DSA2? Is > there another FIPS standard? DSA2 is DSA with SHA-2 support, thus leading to support for longer keys. It is FIPS 186-3. /Simon From agl at imperialviolet.org Sun Oct 14 20:06:14 2007 From: agl at imperialviolet.org (Adam Langley) Date: Sun, 14 Oct 2007 11:06:14 -0700 Subject: [gnutls-dev] GnuTLS 2.1.2 In-Reply-To: <87hcktmves.fsf@mocca.josefsson.org> References: <87hcktmves.fsf@mocca.josefsson.org> Message-ID: <396556a20710141106l2c50fa0nc2d4f8a3372fde3d@mail.gmail.com> On 10/14/07, Simon Josefsson wrote: > ** Added support for DSA2 using libgcrypt 1.3.0. Googling is failing to enlighten me on this point - what's DSA2? Is there another FIPS standard? Thanks, AGL -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org 650-283-9641 From nmav at gnutls.org Sun Oct 14 23:24:32 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Oct 2007 00:24:32 +0300 Subject: [gnutls-dev] 256 bit ciphers In-Reply-To: <877ilqu6zl.fsf@mocca.josefsson.org> References: <200710122328.11634.n.mavrogiannopoulos@gmail.com> <877ilqu6zl.fsf@mocca.josefsson.org> Message-ID: <200710150024.32439.nmav@gnutls.org> On Saturday 13 October 2007, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > Hello, > > I think the 256 ciphers offer no more in security than their 128 bit > > equivalents and they are in general slower. Thus I think it would be a > > good idea to remove them from the default priority lists. Are there any > > objections or good reason to keep them? > > The gnutls_set_default_export_priority function is the same both for > clients and servers, and while it may make sense to only use 128 bits by > default in clients, not supporting 256 bits in servers seems > problematic. What if a client supports AES-256 and ARCFOUR-128 connects > to a GnuTLS server with default settings? Then they would end up with > ARCFOUR-128 which seems bad. > There should probably had been two "default" functions, one for clients > and one for servers, since the defaults may be different. It may be too > late to change that. Indeed. Yes maybe it is a good idea for the default ciphers to contain all the strong supported ciphers. regards, Nikos From simon at josefsson.org Wed Oct 17 17:33:58 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Oct 2007 17:33:58 +0200 Subject: [gnutls-dev] GnuTLS 2.1.3 Message-ID: <87r6jtbvrt.fsf@mocca.josefsson.org> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available Url : /pipermail/attachments/20071017/dd16b99a/attachment.pgp From nmav at gnutls.org Mon Oct 22 22:47:43 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Oct 2007 23:47:43 +0300 Subject: [gnutls-dev] gnutls In-Reply-To: <200710221342.15264.nmav@gnutls.org> References: <200710221342.15264.nmav@gnutls.org> Message-ID: <200710222347.44786.nmav@gnutls.org> On Monday 22 October 2007, Nikos Mavrogiannopoulos wrote: > On Sun, Aug 19, 2007 at 08:38:42AM +0200, Andreas Metzler wrote: > > > Something that might help in debugging without much fuss, would be > > > to test handshake by enabling other ciphersuites. > > > That would be for gnutls-serv to only enable: > > > a. key exchage: DHE-RSA cipher: 3DES > > > b. key exchange: DHE-RSA cipher: AES_256_CBC > > > c. key exchange: RSA cipher ARCFOUR > > > and return the traces if possible. > > I have done these three tests (and a fourth against a gnutls-serv with > > no restrictions for kx and cipher), and have attached the traces. > > Version of gnutls-bin and libgnutls13 is 1.7.19-1. > I have no clue what this could be. I only posses a Sony-Ericsson W810 which > connects to my test gnutls server just fine, so I cannot reproduce or test > it. If you could find a combination of ciphers, protocols, macs that work > with these phones, I'd like to see the trace as well. However since I'm > unable to reproduce I don't expect much. Ok it seems that with the help of Hanno Wagner I managed to debug this issue. These clients fail to understand TLS 1.0 record packets with a padding added. This only occurs when using non stream ciphers (i.e. not arcfour) and does not occur when using SSL 3.0 which does not allow such padding. So one point is for users of these devices to report that as bug. However a fix in gnutls is not easy to do. If we disable the random padding in TLS 1.0 we do disable a nice feature of TLS that protects against statistical attacks. Thus I'd be against such a fix. A solution for the clients would be to only allow SSL 3.0 (if they can configure it). What I can do within gnutls is to add a function to disable this protection and servers that require maximum compatibility could use it. regards, Nikos From ametzler at downhill.at.eu.org Sat Oct 27 14:21:11 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 27 Oct 2007 14:21:11 +0200 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 Message-ID: <20071027122111.GA4807@downhill.g.la> Hello, GnuTLS 2.1.3's configure.in checks for OpenCDK >= 0.6.5, which seems to be nonexistent, except for the copy in libextra/opencdk. Where can I get the full fledged version? - http://developer.berlios.de/projects/opencdk/ which is listed as primay site in README stops at 0.6.1. - Both http://ftp.gnupg.org/gcrypt/alpha/gnutls/opencdk/ and http://josefsson.org/gnutls/releases/opencdk/ stop at 0.6.4. 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 twoaday at gmx.net Sat Oct 27 17:10:36 2007 From: twoaday at gmx.net (Timo Schulz) Date: Sat, 27 Oct 2007 17:10:36 +0200 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <20071027122111.GA4807@downhill.g.la> References: <20071027122111.GA4807@downhill.g.la> Message-ID: <472354EC.9060509@gmx.net> Andreas Metzler wrote: > GnuTLS 2.1.3's configure.in checks for OpenCDK >= 0.6.5, which seems > to be nonexistent, except for the copy in libextra/opencdk. Where can > I get the full fledged version? Maybe this check happened by accident, actually I'm ready to release 0.6.5 but I did not release it yet. > - Both http://ftp.gnupg.org/gcrypt/alpha/gnutls/opencdk/ and > http://josefsson.org/gnutls/releases/opencdk/ stop at 0.6.4. BTW, this site should be preferred over the other site. I will prepare a new release right now and ask Simon to upload it. Timo From simon at josefsson.org Sat Oct 27 23:10:18 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 27 Oct 2007 23:10:18 +0200 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <472354EC.9060509@gmx.net> (Timo Schulz's message of "Sat, 27 Oct 2007 17:10:36 +0200") References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> Message-ID: <87640sqn5x.fsf@mocca.josefsson.org> Timo Schulz writes: > Andreas Metzler wrote: > >> GnuTLS 2.1.3's configure.in checks for OpenCDK >= 0.6.5, which seems >> to be nonexistent, except for the copy in libextra/opencdk. Where can >> I get the full fledged version? > > Maybe this check happened by accident, actually I'm ready to release > 0.6.5 but I did not release it yet. > > >> - Both http://ftp.gnupg.org/gcrypt/alpha/gnutls/opencdk/ and >> http://josefsson.org/gnutls/releases/opencdk/ stop at 0.6.4. > > BTW, this site should be preferred over the other site. > > I will prepare a new release right now and ask Simon to upload it. OpenCDK 0.6.5 should be available now. Btw, I've just prepared GnuTLS 2.1.4 which changes the ABI version from 25 (which is what I got by following libtool's logic) to 14 (which is the next after the old ABI version, 13). Does anyone see a problem of using 14 rather than 25? In any case, please package 2.1.4 rather than 2.1.3 since this decrement the ABI. /Simon From simon at josefsson.org Sat Oct 27 23:12:25 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 27 Oct 2007 23:12:25 +0200 Subject: [gnutls-dev] GnuTLS 2.1.4 Message-ID: <871wbgqn2e.fsf@mocca.josefsson.org> The GnuTLS 2.1.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. News in this release: * Version 2.1.4 (released 2007-10-27) ** Added the --v1 option to certtool, to allow generating X.509 version 1 certificates. ** certtool: Add option --disable-quick-random to enable the old behaviour of using /dev/random to generate keys. ** Added priority functions that accept strings. ** Added gnutls_set_default_priority2() which accepts a flag to indicate priorities preferences. ** Added gnutls_record_disable_padding() to allow servers talking to buggy clients that complain if the TLS 1.0 record protocol padding is used. ** Introduced gnutls_session_enable_compatibility_mode() to allow enabling all supported compatibility options (like disabling padding). ** The gnutls_certificate_set_openpgp_* functions were modified to include the format. This makes the interface consistent with the x509 functions. ** Internal copy of OpenCDK upgraded to version 0.6.5. ** Update gnulib files. ** API and ABI modifications: gnutls_certificate_set_openpgp_key_mem: MODIFIED gnutls_certificate_set_openpgp_key_file: MODIFIED gnutls_certificate_set_openpgp_keyring_mem: MODIFIED gnutls_certificate_set_openpgp_keyring_file: MODIFIED gnutls_set_default_priority: DEPRECATED gnutls_set_default_priority_export: DEPRECATED gnutls_set_default_priority2: ADDED gnutls_session_enable_compatibility_mode: ADDED gnutls_record_disable_padding: ADDED gnutls_mac_convert_priority: ADDED gnutls_compression_convert_priority: ADDED gnutls_protocol_convert_priority: ADDED gnutls_kx_convert_priority: ADDED gnutls_cipher_convert_priority: ADDED gnutls_certificate_type_convert_priority: ADDED gnutls_openpgp_key_t: RENAMED to gnutls_openpgp_crt_t gnutls_openpgp_key_status_t: RENAMED to gnutls_openpgp_crt_status_t gnutls_openpgp_send_key: RENAMED to gnutls_openpgp_send_cert gnutls_openpgp_key_init: RENAMED to gnutls_openpgp_crt_init gnutls_openpgp_key_import: RENAMED to gnutls_openpgp_crt_import gnutls_openpgp_key_export: RENAMED to gnutls_openpgp_crt_export gnutls_openpgp_key_check_hostname: RENAMED to gnutls_openpgp_crt_check_hostname gnutls_openpgp_key_get_creation_time: RENAMED to gnutls_openpgp_crt_get_creation_time gnutls_openpgp_key_get_expiration_time: RENAMED to gnutls_openpgp_crt_get_expiration_time gnutls_openpgp_key_get_fingerprint: RENAMED to gnutls_openpgp_crt_get_fingerprint gnutls_openpgp_key_get_version: RENAMED to gnutls_openpgp_crt_get_version gnutls_openpgp_key_get_pk_algorithm: RENAMED to gnutls_openpgp_crt_get_pk_algorithm gnutls_openpgp_key_get_name: RENAMED to gnutls_openpgp_crt_get_name gnutls_openpgp_key_deinit: RENAMED to gnutls_openpgp_crt_deinit gnutls_openpgp_key_get_id: RENAMED to gnutls_openpgp_crt_get_id gnutls_openpgp_key_get_key_usage: RENAMED to gnutls_openpgp_crt_get_key_usage gnutls_openpgp_key_verify_ring: RENAMED to gnutls_openpgp_crt_verify_ring gnutls_openpgp_key_verify_self: RENAMED to gnutls_openpgp_crt_verify_self The goals for the 2.1.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.2 More ideas are welcome, just create a new ticket. Here are the compressed sources: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.4.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.1.4.tar.bz2 Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available Url : /pipermail/attachments/20071027/0aa682c9/attachment.pgp From ametzler at downhill.at.eu.org Sun Oct 28 09:09:19 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 28 Oct 2007 09:09:19 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <87640sqn5x.fsf@mocca.josefsson.org> References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> Message-ID: <20071028080919.GA4852@downhill.g.la> On 2007-10-27 Simon Josefsson wrote: [...] > Btw, I've just prepared GnuTLS 2.1.4 which changes the ABI version from > 25 (which is what I got by following libtool's logic) to 14 (which is > the next after the old ABI version, 13). Does anyone see a problem of > using 14 rather than 25? [...] Hello, I am not sure. The versioning change looks like this: num c r a 2.0.1 21 4 8 2.1.5 14 0 0 According to libtool's manual this means that 2.0.1 supports interfaces 13, 14, 15, ..., 21 and that 2.1.5 only supports interface 14. This does not reflect the actual interface. However AFAICT it is going to work perfectly on Linux, since libtool cannot express this correctly just in a soname. I have no idea whether it might break on other archs. If it did, libtool would be perfectly right in telling you to keep both pieces. ;-) cu and- Wondering whether libtool's mapping from version to soname is simply broken -reas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From simon at josefsson.org Sun Oct 28 10:27:51 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 28 Oct 2007 10:27:51 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <20071028080919.GA4852@downhill.g.la> (Andreas Metzler's message of "Sun, 28 Oct 2007 09:09:19 +0100") References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> Message-ID: <87y7dnmvvs.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2007-10-27 Simon Josefsson wrote: > [...] >> Btw, I've just prepared GnuTLS 2.1.4 which changes the ABI version from >> 25 (which is what I got by following libtool's logic) to 14 (which is >> the next after the old ABI version, 13). Does anyone see a problem of >> using 14 rather than 25? > [...] > > Hello, > > I am not sure. The versioning change looks like this: > num c r a > 2.0.1 21 4 8 > 2.1.5 14 0 0 > > According to libtool's manual this means that 2.0.1 supports > interfaces 13, 14, 15, ..., 21 and that 2.1.5 only supports interface > 14. This does not reflect the actual interface. However AFAICT it is > going to work perfectly on Linux, since libtool cannot express this > correctly just in a soname. > > I have no idea whether it might break on other archs. If it did, > libtool would be perfectly right in telling you to keep both pieces. > ;-) > cu and- Wondering whether libtool's mapping from version to soname is > simply broken -reas Is there _any_ system on which libtool can express that semantic? I also think there is something broken in how this mapping works. Anyway, it seems we really should use c=25 then, to avoid any possibility of problems on some systems? We can make the change in 2.1.5. /Simon From ametzler at downhill.at.eu.org Sun Oct 28 10:57:30 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 28 Oct 2007 10:57:30 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <87y7dnmvvs.fsf@mocca.josefsson.org> References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> Message-ID: <20071028095730.GC4852@downhill.g.la> On 2007-10-28 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > According to libtool's manual this means that 2.0.1 supports > > interfaces 13, 14, 15, ..., 21 and that 2.1.5 only supports interface > > 14. This does not reflect the actual interface. However AFAICT it is > > going to work perfectly on Linux, since libtool cannot express this > > correctly just in a soname. [...] > Is there _any_ system on which libtool can express that semantic? That is the 100$ question. ;-) > I also think there is something broken in how this mapping works. Perhaps we wil get an answer from libtool upstream, > Anyway, it seems we really should use c=25 then, to avoid any > possibility of problems on some systems? We can make the change in > 2.1.5. I really do not know. One a sidenote, could you bump the symbol versioning please? 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 simon at josefsson.org Sun Oct 28 12:24:50 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 28 Oct 2007 12:24:50 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <20071028095730.GC4852@downhill.g.la> (Andreas Metzler's message of "Sun, 28 Oct 2007 10:57:30 +0100") References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> <20071028095730.GC4852@downhill.g.la> Message-ID: <87r6jfmqgt.fsf@mocca.josefsson.org> Andreas Metzler writes: >> I also think there is something broken in how this mapping works. > > Perhaps we wil get an answer from libtool upstream, > Hopefully... thanks for asking. >> Anyway, it seems we really should use c=25 then, to avoid any >> possibility of problems on some systems? We can make the change in >> 2.1.5. > > I really do not know. > > One a sidenote, could you bump the symbol versioning please? Uhm, where? To what? Do you mean in libgnutls.vers? /Simon From ametzler at downhill.at.eu.org Sun Oct 28 12:39:43 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 28 Oct 2007 12:39:43 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <87r6jfmqgt.fsf@mocca.josefsson.org> References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> <20071028095730.GC4852@downhill.g.la> <87r6jfmqgt.fsf@mocca.josefsson.org> Message-ID: <20071028113943.GD4852@downhill.g.la> On 2007-10-28 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > One a sidenote, could you bump the symbol versioning please? > Uhm, where? To what? Do you mean in libgnutls.vers? Yes, which you have already done in 2.1.4 ;-) cu andreas From simon at josefsson.org Mon Oct 29 11:04:53 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 29 Oct 2007 11:04:53 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <20071028113943.GD4852@downhill.g.la> (Andreas Metzler's message of "Sun, 28 Oct 2007 12:39:43 +0100") References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> <20071028095730.GC4852@downhill.g.la> <87r6jfmqgt.fsf@mocca.josefsson.org> <20071028113943.GD4852@downhill.g.la> Message-ID: <87myu22q4a.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2007-10-28 Simon Josefsson wrote: >> Andreas Metzler writes: > [...] >> > One a sidenote, could you bump the symbol versioning please? > >> Uhm, where? To what? Do you mean in libgnutls.vers? > > Yes, which you have already done in 2.1.4 ;-) Actually, I only bumped the ABI version in configure.in. As far as I have understood the libgnutls.vers discussions, there really won't ever be a time we are going to touch that file. The only time it would be relevant would be if we implement backwards compatibility via versioned symbols, so that an old application will get the old version of a function and a new application will get the new version of the function. But that technique, as far as I understood, is not portable. And we want to be portable. So if you want to be portable, you'll have to bump the ABI version in configure.in, for those platforms that doesn't support dso versioning. And that would break backwards compatibility via the libgnutls.vers approach. Theoretically, I guess we could maintain two ABI versions, one version for platforms that support libgnutls.vers versioning, and one version for other platforms. Then we could make libgnutls.vers work. But this is a lot of work for us, and while I understand a ABI break is going to mean work for packagers, it still is only a one-time cost. ABI breaks also allows us to remove deprecated cruft, which in the long run is a good idea. I still think there is something rotten in the way shared library versioning works with libtool. I suspect I have misunderstood how libgnutls.vers can be used, but when we discussed it last time, I wasn't able to find any "official" documentation that said it should be used in some other way. I think someone should write a 'Practical guide to shared library versioning'. Drepper's PDF is an excellent paper, but it doesn't say what I as maintainer should do in various situations. /Simon From nmav at gnutls.org Mon Oct 29 11:53:42 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Oct 2007 12:53:42 +0200 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <200710291251.14767.nmav@gnutls.org> References: <20071027122111.GA4807@downhill.g.la> <87myu22q4a.fsf@mocca.josefsson.org> <200710291251.14767.nmav@gnutls.org> Message-ID: <200710291253.42140.nmav@gnutls.org> On Monday 29 October 2007, Nikos Mavrogiannopoulos wrote: > > As far as I have understood the libgnutls.vers discussions, there really > > won't ever be a time we are going to touch that file. The only time it > > would be relevant would be if we implement backwards compatibility via > > versioned symbols, so that an old application will get the old version > > of a function and a new application will get the new version of the > > function. But that technique, as far as I understood, is not portable. > > And we want to be portable. So if you want to be portable, you'll have > > to bump the ABI version in configure.in, for those platforms that > > doesn't support dso versioning. And that would break backwards > > compatibility via the libgnutls.vers approach. > > The problem was that in a system with old gnutls and the new one, the > linker was providing symbols to my application from the old gnutls > versions, and only some (the new ones) from the new. This had the problem > of effectively disabling the user_hello callback. This was because my application via some shared library accessed the old gnutls version too, even if it was linked to the new one. From nmav at gnutls.org Mon Oct 29 11:51:14 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Oct 2007 12:51:14 +0200 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <87myu22q4a.fsf@mocca.josefsson.org> References: <20071027122111.GA4807@downhill.g.la> <20071028113943.GD4852@downhill.g.la> <87myu22q4a.fsf@mocca.josefsson.org> Message-ID: <200710291251.14767.nmav@gnutls.org> On Monday 29 October 2007, Simon Josefsson wrote: > > Yes, which you have already done in 2.1.4 ;-) > > Actually, I only bumped the ABI version in configure.in. I did forward it to GNUTLS_1_4 from 1_3. > As far as I have understood the libgnutls.vers discussions, there really > won't ever be a time we are going to touch that file. The only time it > would be relevant would be if we implement backwards compatibility via > versioned symbols, so that an old application will get the old version > of a function and a new application will get the new version of the > function. But that technique, as far as I understood, is not portable. > And we want to be portable. So if you want to be portable, you'll have > to bump the ABI version in configure.in, for those platforms that > doesn't support dso versioning. And that would break backwards > compatibility via the libgnutls.vers approach. The problem was that in a system with old gnutls and the new one, the linker was providing symbols to my application from the old gnutls versions, and only some (the new ones) from the new. This had the problem of effectively disabling the user_hello callback. regards, Nikos From ametzler at downhill.at.eu.org Mon Oct 29 19:52:19 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 29 Oct 2007 19:52:19 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <87myu22q4a.fsf@mocca.josefsson.org> References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> <20071028095730.GC4852@downhill.g.la> <87r6jfmqgt.fsf@mocca.josefsson.org> <20071028113943.GD4852@downhill.g.la> <87myu22q4a.fsf@mocca.josefsson.org> Message-ID: <20071029185219.GA8874@downhill.g.la> On 2007-10-29 Simon Josefsson wrote: > Andreas Metzler writes: > > On 2007-10-28 Simon Josefsson wrote: > >> Andreas Metzler writes: > > [...] > >> > One a sidenote, could you bump the symbol versioning please? > >> Uhm, where? To what? Do you mean in libgnutls.vers? > > Yes, which you have already done in 2.1.4 ;-) > Actually, I only bumped the ABI version in configure.in. ametzler at m26s25:/tmp$ diff -Nur gnutls-2.1.3/ gnutls-2.1.4/ | filterdiff -i'*/*.vers' --- gnutls-2.1.3/lib/libgnutls.vers 2007-09-27 11:17:18.000000000 +0000 +++ gnutls-2.1.4/lib/libgnutls.vers 2007-10-27 18:31:23.000000000 +0000 @@ -20,7 +20,7 @@ # Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301, USA -GNUTLS_1_3 +GNUTLS_1_4 { global: _gnutls*; gnutls*; local: *; Could you bump also lib/libgnutlsxx.vers and libextra/libgnutls-extra.vers, please? > As far as I have understood the libgnutls.vers discussions, there really > won't ever be a time we are going to touch that file. Hello, I am not sure, but I or a fellow Debian maintainer probably has asked for and caused *simple* symbol versioning to be added to gnutls since it helps us a lot for the library transition phase. Just bump the version file whenever the soname changes. If you don't we will get crashes because of conflicting symbols when an application is (at runtime) linked against two different versions of the library. A typical case will include something like this applicationX --> links directly against libbar1 and libgnutls42 libbar1 in turn is linked against libgnutls12 Without (differently) versioned symbols applicationX will crash randomly. With it, it won't. applicationX will automatically use libgnutls42 and any gnutls-invocations from libbar1 will automatically use libgnutls12. --------------------- We still will aim to not have multiple versions of gnutls in a Debian release, since strange things might happen if e.g. gcrypt is initialized twice in one process. 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 Tue Oct 30 10:40:04 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 30 Oct 2007 10:40:04 +0100 Subject: [gnutls-dev] Where to get OpenCDK 0.6.5 In-Reply-To: <20071029185219.GA8874@downhill.g.la> (Andreas Metzler's message of "Mon, 29 Oct 2007 19:52:19 +0100") References: <20071027122111.GA4807@downhill.g.la> <472354EC.9060509@gmx.net> <87640sqn5x.fsf@mocca.josefsson.org> <20071028080919.GA4852@downhill.g.la> <87y7dnmvvs.fsf@mocca.josefsson.org> <20071028095730.GC4852@downhill.g.la> <87r6jfmqgt.fsf@mocca.josefsson.org> <20071028113943.GD4852@downhill.g.la> <87myu22q4a.fsf@mocca.josefsson.org> <20071029185219.GA8874@downhill.g.la> Message-ID: <87zly1lz4b.fsf@mocca.josefsson.org> Andreas Metzler writes: >> > Yes, which you have already done in 2.1.4 ;-) > >> Actually, I only bumped the ABI version in configure.in. > > ametzler at m26s25:/tmp$ diff -Nur gnutls-2.1.3/ gnutls-2.1.4/ | filterdiff -i'*/*.vers' Actually, that was Nikos. :) > Could you bump also lib/libgnutlsxx.vers and > libextra/libgnutls-extra.vers, please? Nikos? >> As far as I have understood the libgnutls.vers discussions, there really >> won't ever be a time we are going to touch that file. > > Hello, > > I am not sure, but I or a fellow Debian maintainer probably has asked > for and caused *simple* symbol versioning to be added to gnutls > since it helps us a lot for the library transition phase. > > Just bump the version file whenever the soname changes. Ok, that is clear enough, and we'll do it. It just isn't clear to me if that is the right thing, as far as libtool and ELF versioning was designed to work. > If you don't we will get crashes because of conflicting symbols when > an application is (at runtime) linked against two different versions > of the library. > > A typical case will include something like this > > applicationX --> links directly against libbar1 and libgnutls42 > libbar1 in turn is linked against libgnutls12 > > Without (differently) versioned symbols applicationX will crash > randomly. With it, it won't. applicationX will automatically use > libgnutls42 and any gnutls-invocations from libbar1 will automatically > use libgnutls12. Good example, thanks. /Simon