From simon at josefsson.org Tue Jul 1 00:23:56 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Jul 2008 00:23:56 +0200 Subject: guile self-tests fail in v.2.5? Message-ID: <87d4lyimtf.fsf@mocca.josefsson.org> Hi Ludovic, On the master trunk there has been some heavy internal changes recently, but no incompatible API changes as far as I understand, and now the guile self-tests fails: make[3]: Entering directory `/home/jas/src/gnutls/guile/tests' guile: uncaught throw to gnutls-error: (# handshake) make[3]: *** [check-TESTS] Interrupt Actually I need to ctrl-c it to cancel it. Do you have any idea? How would I debug this, anyway? I am a bit at a loss when running into any guile problem. Thanks, /Simon From ludo at gnu.org Wed Jul 2 16:34:55 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 02 Jul 2008 16:34:55 +0200 Subject: guile self-tests fail in v.2.5? References: <87d4lyimtf.fsf@mocca.josefsson.org> Message-ID: <87r6acqrqo.fsf@gnu.org> Hi Simon, Please find attached a patch that fixes compilation on `master' (I prefer to let you review it and apply it). Simon Josefsson writes: > On the master trunk there has been some heavy internal changes recently, > but no incompatible API changes as far as I understand, and now the > guile self-tests fails: > > make[3]: Entering directory `/home/jas/src/gnutls/guile/tests' > guile: uncaught throw to gnutls-error: (# handshake) > make[3]: *** [check-TESTS] Interrupt This is `anonymous-auth.scm': `gnutls_handshake ()' returns `GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed above). Adding debugging output (which involves uncommenting the `set-log-level!' and `set-log-procedure!' calls at the top of the file) shows that the error is returned past `auth_dh_common.c:289'. I tried changing the size of the DH prime used on the server-side (the parameter to `make-dh-parameters'), as well as the minimum acceptable DH size on the client side (the `set-session-dh-prime-bits!' parameter) with no success. I vaguely remember seeing a change regarding the default DH prime size, but I couldn't find it. Any hint? Which commit initially triggered the failure? Thanks in advance, Ludovic. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-compilation-of-OpenCDK-with-included-minitasn1.patch Type: text/x-patch Size: 1093 bytes Desc: The patch URL: From simon at josefsson.org Wed Jul 2 17:52:08 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 17:52:08 +0200 Subject: GnuTLS 2.5.0 Message-ID: <877ic4wafr.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. This release contains a merge of Nikos' gnutls_with_mpi branch. It should now be possible to replace the libgcrypt calls to your own callbacks. A lot of low-level code has changed since 2.4.x, so expect this to be unstable. I intend to release 2.5.1 shortly after this release, to indent all code to conform to the GNU Coding Standards. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.0.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.0.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 * Version 2.5.0 (released 2008-07-02) ** Port fixes from v2.4.1 release, see below. ** Added API to replace and update the crypto backend. The header gnutls/crypto.h is now officially supported, and declares the symbols below. ** Rewritten opencdk crypto backend, to use the gnutls internal one. ** Update gnulib and translations. The gnulib gc crypto code has been removed since it was never finished and is no longer even used. An internal non-libgcrypt crypto implementation may be added in the future, but we'll decide that later on. ** API and ABI modifications: gnutls_crypto_bigint_register2: ADDED. gnutls_crypto_cipher_register2: ADDED. gnutls_crypto_digest_register2: ADDED. gnutls_crypto_mac_register2: ADDED. gnutls_crypto_pk_register2: ADDED. gnutls_crypto_rnd_register2: ADDED. gnutls_crypto_single_cipher_register2: ADDED. gnutls_crypto_single_digest_register2: ADDED. gnutls_crypto_single_mac_register2: ADDED. From simon at josefsson.org Wed Jul 2 17:53:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 17:53:27 +0200 Subject: GnuTLS 2.5.1 Message-ID: <87zlp0uvt4.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. This release should contain no changes other than the result of 'make indent' compared to v2.5.0. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.1.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.1.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 * Version 2.5.1 (released 2008-07-02) ** Indent code. ** API and ABI modifications: No changes since last version. From simon at josefsson.org Wed Jul 2 17:57:43 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 17:57:43 +0200 Subject: guile self-tests fail in v.2.5? In-Reply-To: <87r6acqrqo.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 02 Jul 2008 16:34:55 +0200") References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> Message-ID: <87skusuvm0.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi Simon, > > Please find attached a patch that fixes compilation on `master' (I > prefer to let you review it and apply it). Hi Ludovic! May I ask why you added the lib/minitasn1 include? OpenCDK doesn't need libtasn1. Otherwise it looks fine to me. /Simon > From 2ec3592cef768e1de579399d3f9bd725c7dabae7 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Ludovic=20Court=C3=A8s?= > Date: Wed, 2 Jul 2008 16:18:41 +0200 > Subject: [PATCH] Fix compilation of OpenCDK with included minitasn1. > > * lib/opencdk/Makefile.am (INCLUDES): Rename to `AM_CPPFLAGS'. > (AM_CPPFLAGS)[ENABLE_MINITASN1]: Add `lib/miniitasn1'. > --- > lib/opencdk/Makefile.am | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/lib/opencdk/Makefile.am b/lib/opencdk/Makefile.am > index 4dcfeaf..aed03f6 100644 > --- a/lib/opencdk/Makefile.am > +++ b/lib/opencdk/Makefile.am > @@ -20,10 +20,14 @@ > # Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > # MA 02110-1301, USA > > -INCLUDES = -I$(top_srcdir)/lib \ > +AM_CPPFLAGS = -I$(top_srcdir)/lib \ > -I$(top_srcdir)/includes -I$(top_builddir)/includes \ > -I$(top_srcdir)/lgl -I$(top_builddir)/lgl > > +if ENABLE_MINITASN1 > +AM_CPPFLAGS += -I$(top_srcdir)/lib/minitasn1 > +endif > + > noinst_LTLIBRARIES = libminiopencdk.la > > libminiopencdk_la_SOURCES = armor.c filters.h keydb.h main.c types.h \ > -- > 1.5.6.1 > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From simon at josefsson.org Wed Jul 2 18:16:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 18:16:27 +0200 Subject: guile self-tests fail in v.2.5? In-Reply-To: <87r6acqrqo.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 02 Jul 2008 16:34:55 +0200") References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> Message-ID: <87lk0kuuqs.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Simon Josefsson writes: > >> On the master trunk there has been some heavy internal changes recently, >> but no incompatible API changes as far as I understand, and now the >> guile self-tests fails: >> >> make[3]: Entering directory `/home/jas/src/gnutls/guile/tests' >> guile: uncaught throw to gnutls-error: (# handshake) >> make[3]: *** [check-TESTS] Interrupt > > This is `anonymous-auth.scm': `gnutls_handshake ()' returns > `GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed > above). > > Adding debugging output (which involves uncommenting the > `set-log-level!' and `set-log-procedure!' calls at the top of the file) > shows that the error is returned past `auth_dh_common.c:289'. Thanks, that allowed me to track down the problem. It was a silly typo in the dh generation code: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=bc11d56f6461ff0a2afcae7f864bed54a7b337c1 Just getting the gnutls debug log is often sufficient to solve problems like this. I know how to do that for the guile code now... Thanks, Simon From simon at josefsson.org Wed Jul 2 18:42:53 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 18:42:53 +0200 Subject: guile self-tests fail in v.2.5? In-Reply-To: <87lk0kuuqs.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 02 Jul 2008 18:16:27 +0200") References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> <87lk0kuuqs.fsf@mocca.josefsson.org> Message-ID: <878wwkutiq.fsf@mocca.josefsson.org> Simon Josefsson writes: > ludo at gnu.org (Ludovic Court?s) writes: > >> Simon Josefsson writes: >> >>> On the master trunk there has been some heavy internal changes recently, >>> but no incompatible API changes as far as I understand, and now the >>> guile self-tests fails: >>> >>> make[3]: Entering directory `/home/jas/src/gnutls/guile/tests' >>> guile: uncaught throw to gnutls-error: (# handshake) >>> make[3]: *** [check-TESTS] Interrupt >> >> This is `anonymous-auth.scm': `gnutls_handshake ()' returns >> `GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed >> above). >> >> Adding debugging output (which involves uncommenting the >> `set-log-level!' and `set-log-procedure!' calls at the top of the file) >> shows that the error is returned past `auth_dh_common.c:289'. > > Thanks, that allowed me to track down the problem. It was a silly typo > in the dh generation code: > > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=bc11d56f6461ff0a2afcae7f864bed54a7b337c1 Eh, I meant of course: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b32735e1e275c4a2dbf544c04cdf344181fea555 /Simon > Just getting the gnutls debug log is often sufficient to solve problems > like this. I know how to do that for the guile code now... > > Thanks, > Simon From ludo at gnu.org Wed Jul 2 19:29:08 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 02 Jul 2008 19:29:08 +0200 Subject: guile self-tests fail in v.2.5? References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> <87skusuvm0.fsf@mocca.josefsson.org> Message-ID: <87abh0yz2z.fsf@gnu.org> Hi, Simon Josefsson writes: > Hi Ludovic! May I ask why you added the lib/minitasn1 include? OpenCDK > doesn't need libtasn1. Otherwise it looks fine to me. Hmm, it appeared to be needed back then (some C file didn't find ), but now that I've reverted the patch, I can no longer reproduce the problem. So maybe this can be ignored... Thanks, Ludovic. From ludo at gnu.org Wed Jul 2 19:32:38 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 02 Jul 2008 19:32:38 +0200 Subject: guile self-tests fail in v.2.5? References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> <87lk0kuuqs.fsf@mocca.josefsson.org> Message-ID: <87r6acxkcp.fsf@gnu.org> Hi Simon, Simon Josefsson writes: > Thanks, that allowed me to track down the problem. It was a silly typo > in the dh generation code: Good news! Maybe that's an indication that either you should always run the Guile tests, or the test should be duplicated in C. ;-) Thanks, Ludovic. From simon at josefsson.org Wed Jul 2 20:02:01 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 20:02:01 +0200 Subject: guile self-tests fail in v.2.5? In-Reply-To: <87r6acxkcp.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 02 Jul 2008 19:32:38 +0200") References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> <87lk0kuuqs.fsf@mocca.josefsson.org> <87r6acxkcp.fsf@gnu.org> Message-ID: <87y74ki2qu.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi Simon, > > Simon Josefsson writes: > >> Thanks, that allowed me to track down the problem. It was a silly typo >> in the dh generation code: > > Good news! > > Maybe that's an indication that either you should always run the Guile > tests, or the test should be duplicated in C. ;-) I had the exact same thought. :) I prefer to always run the Guile tests, and that is simpler than duplicating it in C. Generating DH pair uses libgcrypt's RNG code, which may be quite slow on some machines, so it shouldn't be used too much in the self tests. Avoiding duplicating it in C helps here. /Simon From simon at josefsson.org Wed Jul 2 20:03:45 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 02 Jul 2008 20:03:45 +0200 Subject: guile self-tests fail in v.2.5? In-Reply-To: <87abh0yz2z.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 02 Jul 2008 19:29:08 +0200") References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org> <87skusuvm0.fsf@mocca.josefsson.org> <87abh0yz2z.fsf@gnu.org> Message-ID: <87tzf8i2ny.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> Hi Ludovic! May I ask why you added the lib/minitasn1 include? OpenCDK >> doesn't need libtasn1. Otherwise it looks fine to me. > > Hmm, it appeared to be needed back then (some C file didn't find > ), but now that I've reverted the patch, I can no longer > reproduce the problem. So maybe this can be ignored... Hi. I applied the first part of your patch, that still looked like the right thing. Thanks, /Simon From colin at colino.net Fri Jul 4 14:07:11 2008 From: colin at colino.net (Colin Leroy) Date: Fri, 4 Jul 2008 14:07:11 +0200 Subject: [PATCH] Little leak fix Message-ID: <20080704140711.5c0c7fcf@paperstreet.colino.net> Hello, I've found out this via valgrind: ==5806== 7,698 (504 direct, 7,194 indirect) bytes in 9 blocks are definitely lost in loss record 175 of 248 ==5806== at 0x4C220BC: calloc (vg_replace_malloc.c:397) ==5806== by 0xED2FE11: _asn1_add_node_only (structure.c:54) ==5806== by 0xED2FFF2: _asn1_copy_structure3 (structure.c:398) ==5806== by 0xED3038D: asn1_create_element (structure.c:690) ==5806== by 0x9733F7A: _gnutls_x509_decode_octet_string (common.c:832) ==5806== by 0x9734243: _gnutls_x509_read_value (common.c:912) ==5806== by 0x974756E: _decode_pkcs12_auth_safe (pkcs12.c:76) ==5806== by 0x9748A67: gnutls_pkcs12_get_bag (pkcs12.c:598) Attached is a patch which fixes it. HTH, -- Colin -------------- next part -------------- A non-text attachment was scrubbed... Name: lib_x509_common_leak.patch Type: text/x-patch Size: 284 bytes Desc: not available URL: From nmav at gnutls.org Sat Jul 5 09:55:43 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Jul 2008 10:55:43 +0300 Subject: [PATCH] Little leak fix In-Reply-To: <20080704140711.5c0c7fcf@paperstreet.colino.net> References: <20080704140711.5c0c7fcf@paperstreet.colino.net> Message-ID: <486F28FF.8070506@gnutls.org> Colin Leroy wrote: > Hello, > > I've found out this via valgrind: > > ==5806== 7,698 (504 direct, 7,194 indirect) bytes in 9 blocks are > definitely lost in loss record 175 of 248 > ==5806== at 0x4C220BC: calloc (vg_replace_malloc.c:397) > ==5806== by 0xED2FE11: _asn1_add_node_only (structure.c:54) > ==5806== by 0xED2FFF2: _asn1_copy_structure3 (structure.c:398) > ==5806== by 0xED3038D: asn1_create_element (structure.c:690) > ==5806== by 0x9733F7A: _gnutls_x509_decode_octet_string (common.c:832) > ==5806== by 0x9734243: _gnutls_x509_read_value (common.c:912) > ==5806== by 0x974756E: _decode_pkcs12_auth_safe (pkcs12.c:76) > ==5806== by 0x9748A67: gnutls_pkcs12_get_bag (pkcs12.c:598) > > Attached is a patch which fixes it. Thank you for the patch. It was applied (slightly modified)! regards, Nikos From nmav at gnutls.org Sat Jul 5 10:21:56 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Jul 2008 11:21:56 +0300 Subject: some opencdk history (was: lib/opencdk/read-packet.c: read_s2k() implementation) In-Reply-To: <87skuzo28j.fsf@squeak.fifthhorseman.net> References: <87skuzo28j.fsf@squeak.fifthhorseman.net> Message-ID: <486F2F24.4010608@gnutls.org> Daniel Kahn Gillmor wrote: > After wrapping my head around the relevant section of RFC 4880 and > bits of opencdk, i've fleshed out the previously unimplemented opencdk > internal function intended to interpret OpenPGP String-To-Key > transformations, read_s2k() in read-packet.c. > > Attached, please find the patch for this function. Inspection with a > debugger shows that the values being stored are congruent with what is > expected in other uses of the cdk_s2k_t construct. > > After my first draft of this patch, i noticed that similar code > already existed in the read_symkey_enc() function (also in > lib/opencdk/read-packet.c). So instead of publishing my first draft, > i've collapsed the code for these two so that there's a canonical > implementation of reading s2k values present in the opencdk codebase. > The attached patch reflects this approach. > > This change should not affect the API or ABI at all, and it allows > GnuTLS to recognize encrypted secret keys (though it cannot yet use > them, afaict). Hello Daniel, I've finally found some time to check your patch and I have some remarks. The first is about patches in opencdk. The opencdk library included in gnutls is a crippled version of the "full" opencdk library by Timo Schulz. This crippling was done for mainly two reasons. The full opencdk library contained GPL code that forced us to include the openpgp support only in libextra, and the second is that we only wanted to include the parts of opencdk we used. Thus if you or anyone wants to add anything to gnutls' opencdk it might be appropriate to check the older opencdk library if it contains the code and is under LGPL. This still will require some porting (since now the included opencdk uses gnutls' internal api) but that wouldn't be that difficult. About the specific patch, it is quite useful, but since it does not affect the gnutls' API or add anything to it, I'll keep from applying it until it is complete. regards, Nikos [0]. http://www.gnu.org/software/gnutls/releases/opencdk/ http://savannah.nongnu.org/projects/opencdk From simon at josefsson.org Tue Jul 8 17:44:08 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jul 2008 17:44:08 +0200 Subject: GnuTLS 2.5.2 Message-ID: <87ej648jp3.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.2.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.2.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 * Version 2.5.2 (released 2008-07-08) ** libgnutls: Fix bug in gnutls_dh_params_generate2. The prime and generator was swapped. ** libgnutls: New interface to register a new TLS extension handler. The new function gnutls_ext_register can be used to register handlers for specific TLS extension types. The callback functions have the new types gnutls_ext_recv_func and gnutls_ext_send_func. A type to classify TLS extensions, gnutls_ext_parse_type_t, has been added as well. ** Move more code for TLS/IA extension from libgnutls to libgnutls-extra. This was made possible by using the new gnutls_ext_register interface. The TLS/IA functionality has only been supported through the libgnutls-extra library, so it makes sense for the code to belong there too. ** API and ABI modifications: gnutls_ext_recv_func: ADDED gnutls_ext_send_func: ADDED gnutls_ext_parse_type_t: ADDED gnutls_ext_register: ADDED -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Tue Jul 8 17:52:27 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Jul 2008 11:52:27 -0400 Subject: some opencdk history In-Reply-To: <486F2F24.4010608@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat\, 05 Jul 2008 11\:21\:56 +0300") References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> Message-ID: <877ibwidac.fsf@squeak.fifthhorseman.net> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote: > I've finally found some time to check your patch and I have some > remarks. The first is about patches in opencdk. The opencdk library > included in gnutls is a crippled version of the "full" opencdk > library by Timo Schulz. This crippling was done for mainly two > reasons. The full opencdk library contained GPL code that forced us > to include the openpgp support only in libextra, and the second is > that we only wanted to include the parts of opencdk we used. Cool, thanks for the explanation, Nikos. Are you saying that the OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then? That they currently fall under the LGPL instead? I know that there has been a lot of changes recently, but i haven't followed them closely enough to know here. Was it necessary to remove the pieces that were removed *because* they were only under the GPL, not the LGPL? Was there a copyright assignment over the OpenCDK sources to the FSF? If so, is the FSF willing to consider re-licensing the code under LGPL so that we can include all the functionality instead of just part of it? > Thus if you or anyone wants to add anything to gnutls' opencdk it > might be appropriate to check the older opencdk library if it > contains the code and is under LGPL. This still will require some > porting (since now the included opencdk uses gnutls' internal api) > but that wouldn't be that difficult. I think you're suggesting to check the source of the older opencdk if anything seems like it is missing from the stripped-down version. Thanks for the pointer; i'll certainly do that. > About the specific patch, it is quite useful, but since it does not > affect the gnutls' API or add anything to it, I'll keep from > applying it until it is complete. Actually, the patch as it stands does add something to the capabilities of libgnutls: consider the case where you have a passphrase-encrypted OpenPGP secret key. Without the patch, GnuTLS will actually choke on the key itself and be unable to even create a gnutls_openpgp_privkey_t from the data (encountering the S2K chunk in the protected key caused a CDK_Not_Implemented). With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such a key. It won't be able to manipulate the key cleanly for any purpose that requires access to the secret MPIs themselves because they are locked, but GnuTLS will still be able to do all of the pubkey functions with that key. For example, It should still be possible to get the fingerprint of the key without knowing the secret MPIs. I consider this to be a useful step (and a bugfix worth pushing into the 2.4.x lines in its own right). I'm also working on trying to take the patches one level further, as you suggest, but i think that proposed change stands alone. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nmav at gnutls.org Wed Jul 9 18:48:58 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 Jul 2008 19:48:58 +0300 Subject: some opencdk history In-Reply-To: <877ibwidac.fsf@squeak.fifthhorseman.net> References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> Message-ID: <4874EBFA.2030208@gnutls.org> Daniel Kahn Gillmor wrote: > On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote: > >> I've finally found some time to check your patch and I have some >> remarks. The first is about patches in opencdk. The opencdk library >> included in gnutls is a crippled version of the "full" opencdk >> library by Timo Schulz. This crippling was done for mainly two >> reasons. The full opencdk library contained GPL code that forced us >> to include the openpgp support only in libextra, and the second is >> that we only wanted to include the parts of opencdk we used. > Cool, thanks for the explanation, Nikos. Are you saying that the > OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then? > That they currently fall under the LGPL instead? I know that there > has been a lot of changes recently, but i haven't followed them > closely enough to know here. > Was it necessary to remove the pieces that were removed *because* they > were only under the GPL, not the LGPL? This wasn't the only reason. Of course the GPL parts had to be removed, but there were also some other parts under LGPL that we didn't use at that time in gnutls and/or required some rewritting, so they were also dropped. > Was there a copyright assignment over the OpenCDK sources to the FSF? > If so, is the FSF willing to consider re-licensing the code under LGPL > so that we can include all the functionality instead of just part of > it? Yes the FSF has relicensed all the parts of opencdk that we needed for proper openpgp certificate support in gnutls. Those are the parts that are now included. > Actually, the patch as it stands does add something to the > capabilities of libgnutls: consider the case where you have a > passphrase-encrypted OpenPGP secret key. Without the patch, GnuTLS > will actually choke on the key itself and be unable to even create a > gnutls_openpgp_privkey_t from the data (encountering the S2K chunk in > the protected key caused a CDK_Not_Implemented). > With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such > a key. It won't be able to manipulate the key cleanly for any purpose > that requires access to the secret MPIs themselves because they are > locked, but GnuTLS will still be able to do all of the pubkey Ah ok... But still in the master git branch some things are required to be added for this patch to work (I remember something that had to do with symmetric encryption was missing). Would you like to add this part as well? > I consider this to be a useful step (and a bugfix worth pushing into > the 2.4.x lines in its own right). I'm also working on trying to take > the patches one level further, as you suggest, but i think that > proposed change stands alone. Ok. I'll include this patch in 2.4.x as well. regards, Nikos From nmav at gnutls.org Wed Jul 9 18:49:59 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 Jul 2008 19:49:59 +0300 Subject: some opencdk history In-Reply-To: <877ibwidac.fsf@squeak.fifthhorseman.net> References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> Message-ID: <4874EC37.1060705@gnutls.org> Daniel Kahn Gillmor wrote: > With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such > a key. It won't be able to manipulate the key cleanly for any purpose > that requires access to the secret MPIs themselves because they are > locked, but GnuTLS will still be able to do all of the pubkey > functions with that key. For example, It should still be possible to > get the fingerprint of the key without knowing the secret MPIs. What will happen if someone tries to access the MPIs? From ludo at gnu.org Wed Jul 9 23:23:21 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 09 Jul 2008 23:23:21 +0200 Subject: some opencdk history References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> <4874EBFA.2030208@gnutls.org> Message-ID: <87skuisqeu.fsf@gnu.org> Hi, Nikos Mavrogiannopoulos writes: > Daniel Kahn Gillmor wrote: >> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote: >> >>> I've finally found some time to check your patch and I have some >>> remarks. The first is about patches in opencdk. The opencdk library >>> included in gnutls is a crippled version of the "full" opencdk >>> library by Timo Schulz. This crippling was done for mainly two >>> reasons. The full opencdk library contained GPL code that forced us >>> to include the openpgp support only in libextra, and the second is >>> that we only wanted to include the parts of opencdk we used. >> Cool, thanks for the explanation, Nikos. Are you saying that the >> OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then? >> That they currently fall under the LGPL instead? I know that there >> has been a lot of changes recently, but i haven't followed them >> closely enough to know here. >> Was it necessary to remove the pieces that were removed *because* they >> were only under the GPL, not the LGPL? > > This wasn't the only reason. Of course the GPL parts had to be removed, > but there were also some other parts under LGPL that we didn't use at > that time in gnutls and/or required some rewritting, so they were also > dropped. Still, the Guile bindings keep providing OpenPGP support as part of the `(gnutls extra)' module, released under the GPLv3+, not the LGPL. Does that mean they're not in sync with core GnuTLS (which wouldn't necessarily be a problem)? Thanks, Ludovic. From dkg-debian.org at fifthhorseman.net Thu Jul 10 04:40:55 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Jul 2008 22:40:55 -0400 Subject: some opencdk history In-Reply-To: <4874EC37.1060705@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed\, 09 Jul 2008 19\:49\:59 +0300") References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> <4874EC37.1060705@gnutls.org> Message-ID: <871w2231hk.fsf@squeak.fifthhorseman.net> On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote: > What will happen if someone tries to access the MPIs? The MPIs associated with a locked secret key are currently set to NULL, so they are rejected by GnuTLS -- attempts to export them result in an error (-50, i believe), but no crash. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nmav at gnutls.org Thu Jul 10 19:10:49 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Jul 2008 20:10:49 +0300 Subject: some opencdk history In-Reply-To: <87skuisqeu.fsf@gnu.org> References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> <4874EBFA.2030208@gnutls.org> <87skuisqeu.fsf@gnu.org> Message-ID: <48764299.6040907@gnutls.org> Ludovic Court?s wrote: > Still, the Guile bindings keep providing OpenPGP support as part of the > `(gnutls extra)' module, released under the GPLv3+, not the LGPL. Does > that mean they're not in sync with core GnuTLS (which wouldn't > necessarily be a problem)? Indeed it should be moved to the core library. regards, Nikos From ludo at gnu.org Thu Jul 10 21:14:04 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 10 Jul 2008 21:14:04 +0200 Subject: some opencdk history References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> <4874EBFA.2030208@gnutls.org> <87skuisqeu.fsf@gnu.org> <48764299.6040907@gnutls.org> Message-ID: <87r6a1blhf.fsf@gnu.org> Hi, Nikos Mavrogiannopoulos writes: > Ludovic Court?s wrote: > >> Still, the Guile bindings keep providing OpenPGP support as part of the >> `(gnutls extra)' module, released under the GPLv3+, not the LGPL. Does >> that mean they're not in sync with core GnuTLS (which wouldn't >> necessarily be a problem)? > > Indeed it should be moved to the core library. Yes, but that would cause an incompatibility for little in return, so I thing we'd be better off leaving things as they are. Thanks, Ludovic. From nmav at gnutls.org Sat Jul 12 11:17:39 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Jul 2008 12:17:39 +0300 Subject: some opencdk history In-Reply-To: <871w2231hk.fsf@squeak.fifthhorseman.net> References: <87skuzo28j.fsf@squeak.fifthhorseman.net> <486F2F24.4010608@gnutls.org> <877ibwidac.fsf@squeak.fifthhorseman.net> <4874EC37.1060705@gnutls.org> <871w2231hk.fsf@squeak.fifthhorseman.net> Message-ID: <487876B3.2020608@gnutls.org> Daniel Kahn Gillmor wrote: > On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote: > >> What will happen if someone tries to access the MPIs? > > The MPIs associated with a locked secret key are currently set to > NULL, so they are rejected by GnuTLS -- attempts to export them result > in an error (-50, i believe), but no crash. I don't know if this is enough. We should have a way to indicate that this key is encrypted otherwise it would not be distinguishable from broken keys. Do you have something in mind for that? From duane at e164.org Thu Jul 24 07:07:44 2008 From: duane at e164.org (Duane) Date: Thu, 24 Jul 2008 15:07:44 +1000 Subject: OpenPGP Browser Support Message-ID: <48880E20.1070101@e164.org> I was pleasantly surprised to learn that OpenPGP has been accepted as a RFC, however I'm unable to find a browser or plugin for a browser that supports this, is anyone able to enlighten me? -- Best regards, Duane -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dkg-debian.org at fifthhorseman.net Thu Jul 24 19:10:15 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Jul 2008 13:10:15 -0400 Subject: OpenPGP Browser Support In-Reply-To: <48880E20.1070101@e164.org> (duane@e164.org's message of "Thu\, 24 Jul 2008 15\:07\:44 +1000") References: <48880E20.1070101@e164.org> Message-ID: <874p6fxl6w.fsf@squeak.fifthhorseman.net> On Thu 2008-07-24 01:07:44 -0400, Duane wrote: > I was pleasantly surprised to learn that OpenPGP has been accepted > as a RFC, however I'm unable to find a browser or plugin for a > browser that supports this, is anyone able to enlighten me? I've yet to find one either, unfortunately. There are two major fields of work to see this happen successfully: * adapt one of the browsers that uses gnutls (epiphany? galeon?) to be able to handle this TLS extension: this includes deciding how to store a keyring of trusted identity certifiers. * do the UI work necessary in that browser to let users choose how to manage their set of trusted identity certifiers. Some implementation decisions would need to be made: * do you want to use/interact with the user's standard GPG keyring for any of this? * do you want to use the full web-of-trust model, or is a list of trusted authorities (similar to the current X.509 model) sufficient? * how do you plan to match the OpenPGP User IDs to hosts? Is just the name sufficient? What about alternate ports? (e.g. is "www.example.com" the User ID you'll look for? or should it be "https://www.example.com/"? Or for alternate ports (e.g. not 443 for https), should it be "www.example.com:4343" ? I don't believe the RFC actually specifies what must go here (though i'd be happy to be shown otherwise). I'd really love to see this project get underway, but i haven't seen anyone doing it yet. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From duane at e164.org Fri Jul 25 00:37:18 2008 From: duane at e164.org (Duane) Date: Fri, 25 Jul 2008 08:37:18 +1000 Subject: OpenPGP Browser Support In-Reply-To: <874p6fxl6w.fsf@squeak.fifthhorseman.net> References: <48880E20.1070101@e164.org> <874p6fxl6w.fsf@squeak.fifthhorseman.net> Message-ID: <4889041E.1070703@e164.org> Daniel Kahn Gillmor wrote: > Some implementation decisions would need to be made: > > * do you want to use/interact with the user's standard GPG keyring > for any of this? This is going to open a can of worms, but disallowing this is detrimental for security, X.509 has a very small amount of deployment because of the 'pop-up tax', there is nothing intrinsically wrong with X.509, however you are fighting mind set if you go down that path. > * do you want to use the full web-of-trust model, or is a list of > trusted authorities (similar to the current X.509 model) > sufficient? There is no practical or technical reason both can't be accommodated, I've already been in contact with the guys from CAcert over this, I'll probably have to do the coding, but they are more than happy to sign OpenPGP keys in the same manner as X.509 certs and given demand I doubt any other CA would choose not to support this as well, money is money after all. > * how do you plan to match the OpenPGP User IDs to hosts? Is just > the name sufficient? What about alternate ports? (e.g. is > "www.example.com" the User ID you'll look for? or should it be > "https://www.example.com/"? Or for alternate ports (e.g. not 443 > for https), should it be "www.example.com:4343" ? I don't believe > the RFC actually specifies what must go here (though i'd be happy > to be shown otherwise). I have some ideas about this as well ;) No the RFC didn't specify what has to go where and this is bad, ideally we need an RFC specifically on this topic and I've been trying to make some head way on this subject but have had a general lack of feed back. I have written in depth about this topic already, so rather than repeat myself I'll just paste a link to the relevant document: http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft Although it doesn't cover port, I'm afraid I don't know enough about the TLS protocol to comment on if https would be suitable or not, but there is always the escalation with TLS, but the downside is information is leaked or changed in transit. These days the way to get a new prefix like https is through SRV records, eg _httpg._tcp ... > I'd really love to see this project get underway, but i haven't seen > anyone doing it yet. Me too! -- Best regards, Duane -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From agl at imperialviolet.org Sat Jul 26 00:16:50 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri, 25 Jul 2008 15:16:50 -0700 Subject: OpenPGP Browser Support In-Reply-To: <4889041E.1070703@e164.org> References: <48880E20.1070101@e164.org> <874p6fxl6w.fsf@squeak.fifthhorseman.net> <4889041E.1070703@e164.org> Message-ID: <396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com> On Thu, Jul 24, 2008 at 3:37 PM, Duane wrote: > I have written in depth about this topic already, so rather than repeat > myself I'll just paste a link to the relevant document: > > http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft This document seems to be dealing with something quite different, namely providing some confidentiality to DNS resolvers. But that's not an uninteresting topic in of itself. However, rather than have queries encrypted to a server and signed replies, I'd suggest that clients include an elliptic-curve Diffie-Hellman public key in the request and encrypt the request with the shared key (assuming that the client know's the server's key). The server than calculates the shared key, encrypts the reply and sticks a MAC on the end. The advantage being that it should be a lot faster. Clients cache the results and there's (effectively) no performance hit. If a server can get a cache hit on the client's public key, it's equally very fast. Otherwise (and this would almost always be the case for root/gTLD servers), you can do about 4000 key agreements/second/core[1]. For a modern, 8-core machine that's 32Kq/s. I can't find recent data on DNS server load at the root or gTLD level, although I suspect it's within an order of magnitude of that. For ISP level server, that should be fine. [1] http://cr.yp.to/ecdh.html -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org From duane at e164.org Sat Jul 26 01:33:50 2008 From: duane at e164.org (Duane) Date: Sat, 26 Jul 2008 09:33:50 +1000 Subject: OpenPGP Browser Support In-Reply-To: <396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com> References: <48880E20.1070101@e164.org> <874p6fxl6w.fsf@squeak.fifthhorseman.net> <4889041E.1070703@e164.org> <396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com> Message-ID: <488A62DE.9090404@e164.org> Adam Langley wrote: > On Thu, Jul 24, 2008 at 3:37 PM, Duane wrote: >> I have written in depth about this topic already, so rather than repeat >> myself I'll just paste a link to the relevant document: >> >> http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft > > This document seems to be dealing with something quite different, > namely providing some confidentiality to DNS resolvers. But that's not > an uninteresting topic in of itself. Sorry about this, but since I posted that I split the draft into 2, well 3, documents. The DNS Encryption stuff, Standardisation of OpenPGP information: http://open-pgp.info/wiki/index.php?title=Standardisation_of_Information_in_OpenPGP_User_IDs_for_Server_Purposes And a chunk of text left over I'm not sure what to do with entirely: http://open-pgp.info/wiki/index.php?title=Why_X.509_is_Bad > However, rather than have queries encrypted to a server and signed > replies, I'd suggest that clients include an elliptic-curve > Diffie-Hellman public key in the request and encrypt the request with > the shared key (assuming that the client know's the server's key). The > server than calculates the shared key, encrypts the reply and sticks a > MAC on the end. The public-key + signed replies are only for session key setup, once established the server/client can switch to AES or some other symmetrical encryption. The reason for signed replies is to prevent spoofed packets from downgrading or sending fake error messages. > If a server can get a cache hit on the client's public key, it's > equally very fast. Otherwise (and this would almost always be the case Actually I'm going the other way, clients are trying to get cache hits on server keys since that's where you need to calculate confidence ratings, the server doesn't need to know anything about the client, in fact the less the server knows about the client the better. > for root/gTLD servers), you can do about 4000 key > agreements/second/core[1]. For a modern, 8-core machine that's 32Kq/s. > I can't find recent data on DNS server load at the root or gTLD level, > although I suspect it's within an order of magnitude of that. For ISP > level server, that should be fine. Actually this will be a little difficult to deal with, a number of root servers have anycast addresses so it will mess with sessions, all the client can do is re-request a new session set-up using the same AES key unless the servers some how share session keys and cookies some how. I suppose I really should make a note about this in the draft. -- Best regards, Duane From duane at e164.org Sun Jul 27 02:27:49 2008 From: duane at e164.org (Duane) Date: Sun, 27 Jul 2008 10:27:49 +1000 Subject: Draft Update Message-ID: <488BC105.6070000@e164.org> Ok, I've made some updates, firstly removing specific references to DNS since this is no longer specifically meant to be for DNS and other changes to remove references to using the user id field, and instead using user attributes to have the information in a format much more suitable for computers, this makes more sense to me than a blob of string doesn't need to be split up and parsed to extract the information. http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes Is there anything I've missed or overlooked at all? -- Best regards, Duane From ludo at gnu.org Sun Jul 27 21:14:07 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 27 Jul 2008 21:14:07 +0200 Subject: Draft Update References: <488BC105.6070000@e164.org> Message-ID: <87abg3w35s.fsf@gnu.org> Hi, Duane writes: > Ok, I've made some updates, firstly removing specific references to DNS > since this is no longer specifically meant to be for DNS and other > changes to remove references to using the user id field, and instead > using user attributes to have the information in a format much more > suitable for computers, this makes more sense to me than a blob of > string doesn't need to be split up and parsed to extract the information. > > http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes > > Is there anything I've missed or overlooked at all? We had a discussion earlier where Daniel Kahn Gillmor proposed (ab)using user IDs in OpenPGP keys in a way similar to what you propose: http://thread.gmane.org/gmane.network.gnutls.general/802/focus=824 Thanks, Ludovic. From duane at e164.org Sun Jul 27 22:57:50 2008 From: duane at e164.org (Duane) Date: Mon, 28 Jul 2008 06:57:50 +1000 Subject: Draft Update In-Reply-To: <87abg3w35s.fsf@gnu.org> References: <488BC105.6070000@e164.org> <87abg3w35s.fsf@gnu.org> Message-ID: <488CE14E.9000009@e164.org> Ludovic Court?s wrote: > We had a discussion earlier where Daniel Kahn Gillmor proposed (ab)using > user IDs in OpenPGP keys in a way similar to what you propose: > > http://thread.gmane.org/gmane.network.gnutls.general/802/focus=824 The RFC ended up pretty much just stating the hostname was to be used in place of other user id information. I actually went a bit further than this, but have since changed it to store the information in User Attribute Types instead. -- Best regards, Duane