From prog1 at yobinario.com Sun Oct 1 15:51:50 2006 From: prog1 at yobinario.com (Unknown) Date: Sun, 01 Oct 2006 15:51:50 +0200 Subject: [Help-gnutls] Strange error in multi-threads Message-ID: <1159710711.3116.11.camel@localhost> Hello, I have a problem with program. I have routines with gnutls functions, and work in program without any problem. The problem is that in multi-thread(apache) segfault. Running apache in debug mode (one thread) the program do not segfault. Have any problem gnutls with threads? Need special parameters? Need special conditions? Any suggestion are wellcome. From regit at inl.fr Sun Oct 1 16:45:51 2006 From: regit at inl.fr (Eric Leblond) Date: Sun, 01 Oct 2006 16:45:51 +0200 Subject: [Help-gnutls] Strange error in multi-threads In-Reply-To: <1159710711.3116.11.camel@localhost> References: <1159710711.3116.11.camel@localhost> Message-ID: <1159713951.5487.4.camel@localhost> Le dimanche 01 octobre 2006 ? 15:51 +0200, Unknown a ?crit : > Hello, > I have a problem with program. > > I have routines with gnutls functions, and work in program without any > problem. > The problem is that in multi-thread(apache) segfault. > > Running apache in debug mode (one thread) the program do not segfault. > > Have any problem gnutls with threads? Need special parameters? > Need special conditions? Yes, the main thing to know is that you can use a single session simultaneously in different threads. BR, > > Any suggestion are wellcome. > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From regit at inl.fr Sun Oct 1 16:50:50 2006 From: regit at inl.fr (Eric Leblond) Date: Sun, 01 Oct 2006 16:50:50 +0200 Subject: [Help-gnutls] Strange error in multi-threads In-Reply-To: <1159713951.5487.4.camel@localhost> References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> Message-ID: <1159714250.5487.7.camel@localhost> Oups, Le dimanche 01 octobre 2006 ? 16:45 +0200, Eric Leblond a ?crit : > Le dimanche 01 octobre 2006 ? 15:51 +0200, Unknown a ?crit : > > Hello, > > Have any problem gnutls with threads? Need special parameters? > > Need special conditions? > > Yes, the main thing to know is that you can use a single session > simultaneously in different threads. That was : "You can't use a TLS session simultaneously in different threads" Sorry for the mistake... -- Eric > > BR, > > > > > Any suggestion are wellcome. > > > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From jas at extundo.com Tue Oct 3 15:44:25 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 03 Oct 2006 15:44:25 +0200 Subject: [Help-gnutls] GnuTLS 1.5.2 - experimental Message-ID: <87lknxjyyu.fsf@latte.josefsson.org> I am happy to announce GnuTLS 1.5.2, a release on the current development branch. We still recommend the 1.4.x branch as the stable version. One goal with the 1.5.x branch is to make Windows x86 a supported platform for GnuTLS. We do this by providing a binary Windows installer of GnuTLS, cross-compiled from GNU/Linux using MinGW and NSIS. The installer is (lightly) tested on Windows 2000 and Windows XP. It is possible to develop applications in Visual Studio or MinGW that links to the library. See http://josefsson.org/gnutls4win/ for more information on the Windows releases. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. * Version 1.5.2 (released 2006-10-03) ** Decrement the shared library version back to 13 (as in the 1.4.x branch). Note that if you installed 1.5.0 or 1.5.1, they will have a higher shared library version than this version, so you'll have to remove them and possibly relink your applications. The reason for this is that no API/ABI changes have been made since the 1.4.x branch, and that incrementing the shared library version was a mistake. Reported by Andreas Metzler . ** Fix off-by-one error when computing length to malloc. The code is used by gnutls_openpgp_add_keyring_file and gnutls_openpgp_add_keyring_mem. Reported by "Adam Langley" . ** Add version script for the GnuTLS C++ library. Reported by Andreas Metzler . ** Fix the C++ compiler detection logic. Reported by Andreas Metzler . ** Update of gnulib files. ** API and ABI modifications: No changes since last version. 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. All manual formats are available from: http://www.gnutls.org/manual/ Direct link to the most popular formats: http://www.gnutls.org/manual/gnutls.html - HTML format http://www.gnutls.org/manual/gnutls.pdf - PDF format http://www.gnutls.org/reference/ch01.html - API Reference, GTK-DOC HTML If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources (4.1MB): http://josefsson.org/gnutls/releases/gnutls-1.5.2.tar.bz2 ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.2.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.5.2.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.2.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2007-02-15] uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 487a28ef457479c1caf16d0ab9985fb0d251a53a gnutls-1.5.2.tar.bz2 ea77991e03269352aeca64e5abc94edf3e7c9d14 gnutls-1.5.2.tar.bz2.sig b32ddc37f98b48eab8efe14df7fced1b7fff4235a06c8fbeb5f9bbb1 gnutls-1.5.2.tar.bz2 a4fb4063071cd1dd76dc95aec7bb70309428ada75cb6220a7fbcbe20 gnutls-1.5.2.tar.bz2.sig Enjoy, Nikos and Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From prog1 at yobinario.com Mon Oct 9 19:55:29 2006 From: prog1 at yobinario.com (Unknown) Date: Mon, 09 Oct 2006 19:55:29 +0200 Subject: [Help-gnutls] Strange error in multi-threads In-Reply-To: <1159714250.5487.7.camel@localhost> References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> <1159714250.5487.7.camel@localhost> Message-ID: <1160416530.3499.12.camel@localhost> Hello, How to synchronize to run only one TLS session? How to wait for another trhead? I use gnutls_global_init () in thread. El dom, 01-10-2006 a las 16:50 +0200, Eric Leblond escribi?: > Oups, > > Le dimanche 01 octobre 2006 ? 16:45 +0200, Eric Leblond a ?crit : > > Le dimanche 01 octobre 2006 ? 15:51 +0200, Unknown a ?crit : > > > Hello, > > > Have any problem gnutls with threads? Need special parameters? > > > Need special conditions? > > > > Yes, the main thing to know is that you can use a single session > > simultaneously in different threads. > > That was : > "You can't use a TLS session simultaneously in different threads" > > Sorry for the mistake... > -- > Eric > > > > > BR, > > > > > > > > Any suggestion are wellcome. > > > > > > > > > _______________________________________________ > > > Help-gnutls mailing list > > > Help-gnutls at gnu.org > > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > From jas at extundo.com Tue Oct 10 14:53:07 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 10 Oct 2006 14:53:07 +0200 Subject: [Help-gnutls] Re: Strange error in multi-threads In-Reply-To: <1160416530.3499.12.camel@localhost> (Unknown's message of "Mon\, 09 Oct 2006 19\:55\:29 +0200") References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> <1159714250.5487.7.camel@localhost> <1160416530.3499.12.camel@localhost> Message-ID: <87mz84mix8.fsf@latte.josefsson.org> Unknown writes: > Hello, > How to synchronize to run only one TLS session? How to wait for another > trhead? > > I use gnutls_global_init () in thread. You'll need to use a mutex from the thread package you use on each gnutls_session variable before (at least) each call to gnutls_record_send and gnutls_record_recv. All functions that modify some internal state in a gnutls_session variable that affects the TLS record protocol need to be protected. E.g., pthread: pthread_mutex_lock (&sessionlock); gnutls_record_send (&session, buf, buflen); pthread_mutex_unlock (&sessionlock); You'll need to keep one mutex variable per session variable. And check error codes etc... Hm. Perhaps there should be an API to tell GnuTLS to call a particular callback function before/after each use of a function that modify the gnutls_session state. /Simon > > > > El dom, 01-10-2006 a las 16:50 +0200, Eric Leblond escribi?: >> Oups, >> >> Le dimanche 01 octobre 2006 ? 16:45 +0200, Eric Leblond a ?crit : >> > Le dimanche 01 octobre 2006 ? 15:51 +0200, Unknown a ?crit : >> > > Hello, >> > > Have any problem gnutls with threads? Need special parameters? >> > > Need special conditions? >> > >> > Yes, the main thing to know is that you can use a single session >> > simultaneously in different threads. >> >> That was : >> "You can't use a TLS session simultaneously in different threads" >> >> Sorry for the mistake... >> -- >> Eric >> >> > >> > BR, >> > >> > > >> > > Any suggestion are wellcome. >> > > >> > > >> > > _______________________________________________ >> > > Help-gnutls mailing list >> > > Help-gnutls at gnu.org >> > > http://lists.gnu.org/mailman/listinfo/help-gnutls >> > >> > >> > >> > _______________________________________________ >> > Help-gnutls mailing list >> > Help-gnutls at gnu.org >> > http://lists.gnu.org/mailman/listinfo/help-gnutls >> From prog1 at yobinario.com Tue Oct 10 15:44:32 2006 From: prog1 at yobinario.com (Unknown) Date: Tue, 10 Oct 2006 15:44:32 +0200 Subject: [Help-gnutls] Re: Strange error in multi-threads In-Reply-To: <87mz84mix8.fsf@latte.josefsson.org> References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> <1159714250.5487.7.camel@localhost> <1160416530.3499.12.camel@localhost> <87mz84mix8.fsf@latte.josefsson.org> Message-ID: <1160487874.2944.14.camel@localhost> El mar, 10-10-2006 a las 14:53 +0200, Simon Josefsson escribi?: > pthread_mutex_lock (&sessionlock); > gnutls_record_send (&session, buf, buflen); > pthread_mutex_unlock (&sessionlock); > > You'll need to keep one mutex variable per session variable. And > check error codes etc... > > Hm. Perhaps there should be an API to tell GnuTLS to call a > particular callback function before/after each use of a function that > modify the gnutls_session state. > > /Simon > I only use functions that manage certificates. I do not use: > gnutls_record the strange of this, is that in single program that call my function works without any problem, and in apache in single thread works. But in apache with normal mode(n threads) as module, segfault when DSO module run. At this time I can not debug the problem. From jas at extundo.com Tue Oct 10 16:34:57 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 10 Oct 2006 16:34:57 +0200 Subject: [Help-gnutls] Re: Strange error in multi-threads In-Reply-To: <1160487536.2944.12.camel@localhost> (Unknown's message of "Tue\, 10 Oct 2006 15\:38\:55 +0200") References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> <1159714250.5487.7.camel@localhost> <1160416530.3499.12.camel@localhost> <87mz84mix8.fsf@latte.josefsson.org> <1160487536.2944.12.camel@localhost> Message-ID: <877iz8me7i.fsf@latte.josefsson.org> Please use the list for discussion, so others can learn from it. Unknown writes: > El mar, 10-10-2006 a las 14:53 +0200, Simon Josefsson escribi?: > >> pthread_mutex_lock (&sessionlock); >> gnutls_record_send (&session, buf, buflen); >> pthread_mutex_unlock (&sessionlock); >> >> You'll need to keep one mutex variable per session variable. And >> check error codes etc... >> >> Hm. Perhaps there should be an API to tell GnuTLS to call a >> particular callback function before/after each use of a function that >> modify the gnutls_session state. >> >> /Simon >> > > I only use functions that manage certificates. I do not use: >> gnutls_record > the strange of this, is that in single program that call my function > works without any problem, and in apache in single thread works. But in > apache with normal mode(n threads) as module, segfault when DSO module > run. At this time I can not debug the problem. Oh, that's interesting. Can you provide a gdb backtrace? Is your code threaded? If yes, does it also crash when you limit the number of threads to one? (If this is possible..) If your code isn't threaded, perhaps this is some general problem with apache threading. I'm assuming that you don't have any other global variables (like credential variables) in your code that you use from multiple threads. /Simon From prog1 at yobinario.com Wed Oct 11 09:57:41 2006 From: prog1 at yobinario.com (Unknown) Date: Wed, 11 Oct 2006 09:57:41 +0200 Subject: [Help-gnutls] Re: Strange error in multi-threads In-Reply-To: <877iz8me7i.fsf@latte.josefsson.org> References: <1159710711.3116.11.camel@localhost> <1159713951.5487.4.camel@localhost> <1159714250.5487.7.camel@localhost> <1160416530.3499.12.camel@localhost> <87mz84mix8.fsf@latte.josefsson.org> <1160487536.2944.12.camel@localhost> <877iz8me7i.fsf@latte.josefsson.org> Message-ID: <1160553461.2938.12.camel@localhost> El mar, 10-10-2006 a las 16:34 +0200, Simon Josefsson escribi?: > Unknown writes: > Oh, that's interesting. Can you provide a gdb backtrace? At this moment I can not debug DSO module. I am trying to learn it. > Is your code threaded? If yes, does it also crash when you limit the > number of threads to one? (If this is possible..) Code have not threads, the thread is the apache thread yhat call DSO module. > If your code isn't threaded, perhaps this is some general problem with > apache threading. > > I'm assuming that you don't have any other global variables (like > credential variables) in your code that you use from multiple threads. > > /Simon I made a test, comment this: /* gnutls_global_init ();*/ out this: > operation is not possible without initialized secure memory but no segfault. mod_ssl is enabled and working. At this moment I can not debug more. From jas at extundo.com Wed Oct 11 17:03:42 2006 From: jas at extundo.com (Simon Josefsson) Date: Wed, 11 Oct 2006 17:03:42 +0200 Subject: [Help-gnutls] OpenCDK 0.5.10 Message-ID: <873b9uki7l.fsf@latte.josefsson.org> The OpenCDK library implement basic parts of the OpenPGP message format. Due to some possible security problems, the library also implements parts of draft-ietf-openpgp-rfc2440bis-08.txt. The aim of the library is *not* to replace any available OpenPGP version. There will be no real support for key management (sign, revoke, alter preferences, ...) and some other parts are only rudimentary available. The main purpose is to handle and understand OpenPGP packets and to use basic operations. For example, encrypt/decrypt, sign/verify and packet parsing routines. Noteworthy changes in version 0.5.10 (2006-10-11) ------------------------------------------------ * Fix double-free in cdk_pklist_encrypt, reported by Adam Langley. * Fix keydb_idx_search() to handle keys at offset 0, thanks to Adam Langley. * A pkg-config script was added, thanks to Andreas Metzler. * Autobuild time stamps are used, for easier build robot testing. Commercial support contracts for OpenCDK are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding OpenCDK maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use OpenCDK, or want to help others, you are invited to join our help-gnutls mailing list, see: . Here are the compressed sources (1.2MB): http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.10.tar.gz ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.10.tar.gz Here are GPG detached signatures using key 0xB565716F: http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.10.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.10.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2007-02-15] uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: db4af36730dcbb2ab9ac93f6ce1ec27e5a36876f opencdk-0.5.10.tar.gz 9259cdf60825d4e302349d6572b51f43ab4ff14d opencdk-0.5.10.tar.gz.sig a334e13b0b246c4af85d60936c73a453b73d482e915a09ae5cadb2e8 opencdk-0.5.10.tar.gz 8bce4e01c874a3197518970f95763367ed62112a781f97bc78a0ad99 opencdk-0.5.10.tar.gz.sig Enjoy, Timo, Nikos, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From david.harris.uk at gmail.com Mon Oct 16 19:10:16 2006 From: david.harris.uk at gmail.com (david harris) Date: Mon, 16 Oct 2006 18:10:16 +0100 Subject: [Help-gnutls] building gnutls under OSx Message-ID: <17412ab80610161010q262563b7ve09bf78f7dd0205@mail.gmail.com> hi, I get this error when building gnutls under OSx 10.4: ld: Undefined symbols: _deflate _deflateEnd _deflateInit2_ _deflateInit_ _inflate _inflateEnd _inflateInit2_ _inflateInit_ The (abbreviated) compile message is " gcc -dynamiclib -o .libs/libgnutls-extra.13.0.9.dylib .libs/gnutls_extra.o .libs/gnutls_openpgp.o .libs/gnutls_ia.o .libs/libgnutls-extra.lax/libgnutls_openpgp.a/compat.o .libs/libgnutls-extra.lax/libgnutls_openpgp.a/extras.o .libs/libgnutls- extra.lax/libgnutls_openpgp.a/pgp.o .libs/libgnutls-extra.lax /libgnutls_openpgp.a/pgpverify.o .libs/libgnutls-extra.lax/libgnutls_openpgp.a/privkey.o .libs/libgnutls-extra.lax/libgnutls_openpgp.a/xml.o .libs/libgnutls- extra.lax/libminiopencdk.a/armor.o .libs/libgnutls-extra.lax/libminiopencdk.a/cipher.o .libs/libgnutls-extra.lax/libminiopencdk.a/compress.o .libs/libgnutls- extra.lax/libminiopencdk.a/encrypt.o .libs/libgnutls-extra.lax/libminiopencdk.a/kbnode.o .libs/libgnutls-extra.lax/libminiopencdk.a/keydb.o .libs/libgnutls-extra.lax/libminiopencdk.a/keygen.o .libs/libgnutls-extra.lax/libminiopencdk.a/keylist.o .libs/libgnutls- extra.lax/libminiopencdk.a/keyserver.o .libs/libgnutls-extra.lax/libminiopencdk.a/main.o .libs/libgnutls-extra.lax/libminiopencdk.a/md.o .libs/libgnutls-extra.lax/libminiopencdk.a/misc.o .libs/libgnutls-extra.lax/libminiopencdk.a/new-packet.o .libs/libgnutls- extra.lax/libminiopencdk.a/plaintext.o .libs/libgnutls-extra.lax/libminiopencdk.a/pubkey.o .libs/libgnutls-extra.lax/libminiopencdk.a/read-packet.o .libs/libgnutls- extra.lax/libminiopencdk.a/seskey.o .libs/libgnutls-extra.lax /libminiopencdk.a/sig-check.o .libs/libgnutls-extra.lax/libminiopencdk.a/sign.o .libs/libgnutls-extra.lax/libminiopencdk.a/stream.o .libs/libgnutls- extra.lax/libminiopencdk.a/sym-cipher.o .libs/libgnutls-extra.lax/libminiopencdk.a/trustdb.o .libs/libgnutls-extra.lax/libminiopencdk.a/verify.o .libs/libgnutls- extra.lax/libminiopencdk.a/write-packet.o .libs/libgnutls-extra.lax/libgnu.a/asnprintf.o .libs/libgnutls-extra.lax/libgnu.a/dummy.o .libs/libgnutls-extra.lax /libgnu.a/gc-libgcrypt.o .libs/libgnutls-extra.lax/libgnu.a/gc-pbkdf2-sha1.o.libs/libgnutls- extra.lax/libgnu.a/getdelim.o .libs/libgnutls-extra.lax/libgnu.a/getline.o .libs/libgnutls-extra.lax/libgnu.a/md2.o .libs/libgnutls-extra.lax/libgnu.a/memmem.o .libs/libgnutls-extra.lax/libgnu.a/printf-args.o .libs/libgnutls-extra.lax /libgnu.a/printf-parse.o .libs/libgnutls-extra.lax/libgnu.a/vasnprintf.o .libs/libgnutls-extra.lax/libminilzo.a/minilzo.o ..*/lib/*.libs/libgnutls.dylib -L/usr/local/lib /usr/local/lib/libgcrypt.dylib -L/opt/local/lib /opt/local/lib/libgpg-error.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -install_name /usr/local/lib/libgnutls- extra.13.dylib -Wl,-compatibility_version -Wl,14 -Wl,-current_version -Wl, 14.9 ld: warning multiple definitions of symbol _gc_hmac_md5 .[] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hmac_md5 [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hmac_sha1 ld: warning multiple definitions of symbol _gc_md2 [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_md2 ld: warning multiple definitions of symbol _gc_md4 [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_md4 ld: warning multiple definitions of symbol _gc_md5 [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_md5 ld: warning multiple definitions of symbol _gc_random [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_random ld: warning multiple definitions of symbol _gc_sha1 [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_sha1 ld: warning multiple definitions of symbol _gc_cipher_setkey [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_setkey ld: warning multiple definitions of symbol _gc_cipher_setiv [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_setiv ld: warning multiple definitions of symbol _gc_cipher_open [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_open ld: warning multiple definitions of symbol _gc_cipher_encrypt_inline [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_encrypt_inline ld: warning multiple definitions of symbol _gc_pseudo_random [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_pseudo_random ld: warning multiple definitions of symbol _gc_cipher_decrypt_inline [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_decrypt_inline ld: warning multiple definitions of symbol _gc_cipher_close [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_cipher_close ld: warning multiple definitions of symbol _gc_hash_write [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_write ld: warning multiple definitions of symbol _gc_hash_read [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_read ld: warning multiple definitions of symbol _gc_hash_open [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_open ld: warning multiple definitions of symbol _gc_hash_hmac_setkey [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_hmac_setkey ld: warning multiple definitions of symbol _gc_hash_digest_length [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_digest_length ld: warning multiple definitions of symbol _gc_hash_close [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_close ld: warning multiple definitions of symbol _gc_hash_clone [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_clone ld: warning multiple definitions of symbol _gc_nonce [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_nonce ld: warning multiple definitions of symbol _gc_set_allocators [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_set_allocators ld: warning multiple definitions of symbol _gc_hash_buffer [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_hash_buffer ld: warning multiple definitions of symbol _gc_done [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_done ld: warning multiple definitions of symbol _gc_init [] ..*/lib/*.libs/libgnutls.dylib(gc-libgcrypt.o) definition of _gc_init ld: warning multiple definitions of symbol _memmem [] ..*/lib/*.libs/libgnutls.dylib(memmem.o) definition of _memmem ld: warning multiple definitions of symbol _md2_process_bytes [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_process_bytes ld: warning multiple definitions of symbol _md2_finish_ctx [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_finish_ctx ld: warning multiple definitions of symbol _md2_buffer [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_buffer ld: warning multiple definitions of symbol _md2_stream [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_stream ld: warning multiple definitions of symbol _md2_process_block [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_process_block ld: warning multiple definitions of symbol _md2_read_ctx [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_read_ctx ld: warning multiple definitions of symbol _md2_init_ctx [] ..*/lib/*.libs/libgnutls.dylib(md2.o) definition of _md2_init_ctx ld: warning multiple definitions of symbol _gc_pbkdf2_sha1 [] ld: Undefined symbols: _deflate _deflateEnd _deflateInit2_ _deflateInit_ _inflate _inflateEnd _inflateInit2_ _inflateInit_ " Not sure where the error arises: I Googled and though it might be a zlib issue so I built the latest zlib but that didnt help. Can anyone suggest anything? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jas at extundo.com Thu Oct 19 21:20:49 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 19 Oct 2006 21:20:49 +0200 Subject: [Help-gnutls] Libtasn1 0.3.7 Message-ID: <87mz7sru26.fsf@latte.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by Shishi to handle Kerberos V5 packets. Version 0.3.7 (released 2006-10-19) - When asn1_der_coding encoded a TYPE_NULL and the output buffer is NULL, it would not increment the counter properly, so the size of the required buffer would be off by one. Fixed. Reported by Stephen Wrobleski . - Fix configure to respect user-definable flags. Reported by "Diego 'Flameeyes' Petten?" . - The --help and --version outputs from the tools have been improved. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Manual in many formats: http://josefsson.org/gnutls/manual/libtasn1/ Here are the compressed sources (1.3MB): http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.7.tar.gz Here are GPG detached signatures using key 0xB565716F: http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.7.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2006-08-14] 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: 2006-08-14] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 3b742b451999f97ab564cb9c8429eb4d48816029 libtasn1-0.3.7.tar.gz 62202a34d4bef421a2b162bebf0351120a672c83 libtasn1-0.3.7.tar.gz.sig 6bf5f6537934dc1b960f52d67ddeac12805a0eb6c81d36eedf117543 libtasn1-0.3.7.tar.gz 85782c986a7fa8619dadff80e96ff7a144747e85a88139a972ac0fdb libtasn1-0.3.7.tar.gz.sig Enjoy, Fabio, Nikos and Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From bradh at frogmouth.net Fri Oct 20 07:11:34 2006 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 20 Oct 2006 15:11:34 +1000 Subject: [Help-gnutls] Generating an RSA key Message-ID: <200610201511.47211.bradh@frogmouth.net> I'm trying to write some code that generates RSA keys (given either the raw parameters, and also given the exponent and bit size), and then extract various things (bit size, public key), and some I/O in DER and PEM formats. I'd prefer it if I could avoid learning the sexp stuff used in libgcrypt. However I can't find the right part of the API. Does anyone have a suggestion or example code that they would be willing to share? Thanks Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jas at extundo.com Tue Oct 24 08:34:46 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 24 Oct 2006 08:34:46 +0200 Subject: [Help-gnutls] Re: target collisions and colliding certificates with different identities In-Reply-To: (B. M. M. de Weger's message of "Mon\, 23 Oct 2006 23\:58\:21 +0200") References: Message-ID: <87k62qgr21.fsf@latte.josefsson.org> All, You may have seen the post below about colliding X.509 certificates with different identities. GnuTLS since 1.2.9 is not vulnerable to this problem, since we have disabled the use of RSA-MD5 for verifying X.509 signatures. Below is how to test this for yourself. /Simon jas at mocca:~$ wget -q http://www.win.tue.nl/~bdeweger/CollidingCertificates/MD5CollisionCA.cer http://www.win.tue.nl/hashclash/TargetCollidingCertificates/TargetCollidingCertificate1.cer http://www.win.tue.nl/hashclash/TargetCollidingCertificates/TargetCollidingCertificate2.cer jas at mocca:~$ certtool --inder -i < MD5CollisionCA.cer > ca.pem Warning: certificate uses a broken signature algorithm that can be forged. jas at mocca:~$ certtool --inder -i < TargetCollidingCertificate1.cer > client1.pem Warning: certificate uses a broken signature algorithm that can be forged. jas at mocca:~$ certtool --inder -i < TargetCollidingCertificate2.cer > client2.pem Warning: certificate uses a broken signature algorithm that can be forged. jas at mocca:~$ cat client1.pem ca.pem > chain1.pem jas at mocca:~$ cat client2.pem ca.pem > chain2.pem jas at mocca:~$ certtool -e < chain1.pem Certificate[0]: CN=Arjen K. Lenstra,O=Collisionairs,L=Eindhoven,C=NL Issued by: CN=Hash Collision CA,L=Eindhoven,C=NL Verifying against certificate[1]. Verification output: Not verified, Insecure algorithm. Certificate[1]: CN=Hash Collision CA,L=Eindhoven,C=NL Issued by: CN=Hash Collision CA,L=Eindhoven,C=NL Verification output: Verified. jas at mocca:~$ certtool -e < chain2.pem Certificate[0]: CN=Marc Stevens,O=Collision Factory,L=Eindhoven,C=NL Issued by: CN=Hash Collision CA,L=Eindhoven,C=NL Verifying against certificate[1]. Verification output: Not verified, Insecure algorithm. Certificate[1]: CN=Hash Collision CA,L=Eindhoven,C=NL Issued by: CN=Hash Collision CA,L=Eindhoven,C=NL Verification output: Verified. jas at mocca:~$ "Weger, B.M.M. de" writes: > Hi all, > > We announce: > - an example of a target collision for MD5; this means: > for two chosen messages m1 and m2 we have constructed > appendages b1 and b2 to make the messages collide > under MD5, i.e. MD5(m1||b1) = MD5(m2||b2); > said differently: we can cause an MD5 collision for > any pair of distinct IHVs; > - an example of a pair of valid, unsuspicious X.509 > certificates with distinct Distinguished Name fields, > but identical CA signatures; this example makes use > of the target collision. > > See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/, > where the certificates and a more detailed announcement > can be found. > > Marc Stevens > Arjen Lenstra > Benne de Weger From jas at extundo.com Thu Oct 26 14:08:59 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 26 Oct 2006 14:08:59 +0200 Subject: [Help-gnutls] OpenCDK 0.5.11 Message-ID: <871wov8ejo.fsf@latte.josefsson.org> The OpenCDK library implement basic parts of the OpenPGP message format. Due to some possible security problems, the library also implements parts of draft-ietf-openpgp-rfc2440bis-08.txt. The aim of the library is *not* to replace any available OpenPGP version. There will be no support for key management (sign, revoke, alter preferences, ...) and some other parts are only rudimentary available. The main purpose is to handle and understand OpenPGP packets and to use basic operations. For example, encrypt/decrypt, sign/verify and packet parsing routines. The library is used by GnuTLS for OpenPGP support. Noteworthy changes in version 0.5.11 (2006-10-26) ------------------------------------------------ * Add a new self test "basic" to test cdk_check_version. * Add prototype of cdk_stream_decrypt to opencdk.h, reported by Adam Langley. * Fix crash in cdk_data_transform triggered by self-tests. Commercial support contracts for OpenCDK are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding OpenCDK maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use OpenCDK, or want to help others, you are invited to join our help-gnutls mailing list, see: . Here are the compressed sources (512KB): http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.11.tar.gz ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.11.tar.gz Here are GPG detached signatures using key 0xB565716F: http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.11.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.11.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2007-02-15] uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: c89bae403acfac96e8e987355cf9b633b0186fd3 opencdk-0.5.11.tar.gz 99830333678a2fd196cc7721d89f5bd6834002b5 opencdk-0.5.11.tar.gz.sig 7d57dcfba8f30e63a39ef148ee34c81a6f107b95861d4c0ca2539de3 opencdk-0.5.11.tar.gz 5687fab260c970b07c073350fa31b023636e4ee246fc0e53eda66c19 opencdk-0.5.11.tar.gz.sig Enjoy, Timo, Nikos, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From ludovic.courtes at laas.fr Thu Oct 26 17:02:31 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 26 Oct 2006 17:02:31 +0200 Subject: [Help-gnutls] Failure to import an OpenPGP private key Message-ID: <87u01rxgqg.fsf@laas.fr> Hi, I tried importing the ASCII-armored OpenPGP secret key available under `src/openpgp/sec.asc' as follows: err = gnutls_openpgp_privkey_import (privkey, &key_content, GNUTLS_OPENPGP_FMT_BASE64, "" /* empty passphrase */, 0 /* flags? */); It systematically returns `GNUTLS_E_OPENPGP_GETKEY_FAILED'. This is actually the exact same problem that I reported a while back [0]. Could you please comment on this? Thanks in advance, Ludovic. PS: This time I'm using 1.4.4 from Debian unstable. [0] http://lists.gnu.org/archive/html/help-gnutls/2006-08/msg00011.html From jas at extundo.com Thu Oct 26 17:08:17 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 26 Oct 2006 17:08:17 +0200 Subject: [Help-gnutls] GnuTLS 1.5.3 - experimental Message-ID: <87bqnznmhq.fsf@latte.josefsson.org> I am happy to announce GnuTLS 1.5.3, a release on the current development branch. We still recommend the 1.4.x branch as the stable version. One goal with the 1.5.x branch is to make Windows x86 a supported platform for GnuTLS. We do this by providing a binary Windows installer of GnuTLS, cross-compiled from GNU/Linux using MinGW and NSIS. The installer is (lightly) tested on Windows 2000 and Windows XP. It is possible to develop applications in Visual Studio or MinGW that links to the library. See http://josefsson.org/gnutls4win/ for more information on the Windows releases. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. * Version 1.5.3 (released 2006-10-26) ** Add new self-test of RSA-MD5 signature chains. Note that we already, since GnuTLS 1.2.9, reject RSA-MD5 signatures when verifying X.509 chains. The code is in tests/rsa-md5-collision/ and is based on the work by Marc Stevens et al, see . ** Re-factor self tests. ** The include copy of Libtasn1 is updated to version 0.3.7. ** The included copy of OpenCDK is updated to version 0.5.11. ** Fix the filename of the *.def file on Windows after library version bump. ** Separated the gnulib directory into one for LGPL modules and one for GPL. This allows the GPL'd part of GnuTLS to take advantage of the GPL'd gnulib modules. Earlier we could only use the LGPL'ed module from gnulib, because two gnulib directories in the same project didn't work. ** API and ABI modifications: No changes since last version. 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. All manual formats are available from: http://www.gnutls.org/manual/ Direct link to the most popular formats: http://www.gnutls.org/manual/gnutls.html - HTML format http://www.gnutls.org/manual/gnutls.pdf - PDF format http://www.gnutls.org/reference/ch01.html - API Reference, GTK-DOC HTML If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources (4.1MB): http://josefsson.org/gnutls/releases/gnutls-1.5.3.tar.bz2 ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.3.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.5.3.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.3.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2007-02-15] uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: f71a2a9fd09b2a1f7c368cd9eebb16d47feadff9 gnutls-1.5.3.tar.bz2 10011a138fb4cca9a09ab719e6e4c2642fff922b gnutls-1.5.3.tar.bz2.sig e4fc78b35c571c278db5771533d71b566242156efcfc3a3f8a99c5c1 gnutls-1.5.3.tar.bz2 944072cc6d54f22c9699fac33624d75a0864b675e462665cfd546fcf gnutls-1.5.3.tar.bz2.sig Enjoy, Nikos and Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From jas at extundo.com Thu Oct 26 20:44:26 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 26 Oct 2006 20:44:26 +0200 Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key In-Reply-To: <87u01rxgqg.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Thu\, 26 Oct 2006 17\:02\:31 +0200") References: <87u01rxgqg.fsf@laas.fr> Message-ID: <87lkn2or1x.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > I tried importing the ASCII-armored OpenPGP secret key available under > `src/openpgp/sec.asc' as follows: > > err = gnutls_openpgp_privkey_import (privkey, &key_content, > GNUTLS_OPENPGP_FMT_BASE64, > "" /* empty passphrase */, > 0 /* flags? */); > > It systematically returns `GNUTLS_E_OPENPGP_GETKEY_FAILED'. This is > actually the exact same problem that I reported a while back [0]. Could > you please comment on this? Hi Ludovic, I'm sorry for the slow response. It is probably a bug in OpenCDK. Your best bet is to debug this further yourself, like using gdb to find where the error is triggered, and possibly try to guess why it happens and how to fix it. I don't think it has anything to do with remote servers, which you suggested in your last post -- there is no such functionality in GnuTLS/OpenCDK as far as I know. OpenCDK, and generally the OpenPGP support in GnuTLS, is not well tested or maintained, and while I have interest in seeing it work, I don't have the time or resources to make that happen right now. Paypal contributions would help.. ;-) We could also consider if OpenCDK is the best option here, or whether it is possible to somehow use GnuPG instead. Using gpg might have other good side effects, such as nice smart card integration, and better web-of-trust management. This approach might mean more work initially, though. /Simon From ludovic.courtes at laas.fr Fri Oct 27 11:26:16 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 27 Oct 2006 11:26:16 +0200 Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org> Message-ID: <87wt6mkt3b.fsf@laas.fr> Hi, Simon Josefsson writes: > ludovic.courtes at laas.fr (Ludovic Court?s) writes: > >> Hi, >> >> I tried importing the ASCII-armored OpenPGP secret key available under >> `src/openpgp/sec.asc' as follows: >> >> err = gnutls_openpgp_privkey_import (privkey, &key_content, >> GNUTLS_OPENPGP_FMT_BASE64, >> "" /* empty passphrase */, >> 0 /* flags? */); >> >> It systematically returns `GNUTLS_E_OPENPGP_GETKEY_FAILED'. This is >> actually the exact same problem that I reported a while back [0]. Could >> you please comment on this? > > Hi Ludovic, I'm sorry for the slow response. > > It is probably a bug in OpenCDK. Your best bet is to debug this > further yourself, like using gdb to find where the error is triggered, > and possibly try to guess why it happens and how to fix it. Looking at `cdk_pkt_read ()' (which is used by `cdk_keydb_get_keyblock ()', which in turn is called by `gnutls_openpgp_privkey_import ()') allowed me to guess that CDK actually expects _binary_ private keys and not ASCII-armored keys. Thus, I tried passing it a private key produced by: $ gpg --export-secret-key THE-KEY and importing it does indeed work. This can be seen as a GnuTLS bug since the FORMAT argument of `gnutls_openpgp_privkey_import' is not honored. Does CDK provide a way to import ASCII-armored private keys? Otherwise, `privkey_import' should return `UNIMPLEMENTED_FEATURE' when FORMAT is not `RAW'. BTW, is there an API documentation for OpenCDK? Some of the function names are self-explanatory, but some are not. In particular, I don't understand the `keydb' in `cdk_keydb_get_keyblock'. > I don't think it has anything to do with remote servers, which you > suggested in your last post -- there is no such functionality in > GnuTLS/OpenCDK as far as I know. I was wondering what `GETKEY_FAILED' could really mean. From my current understanding, it seems that `IMPORT_FAILED' would be more appropriate. > We could also consider if OpenCDK is the best option here, or whether > it is possible to somehow use GnuPG instead. Using gpg might have > other good side effects, such as nice smart card integration, and > better web-of-trust management. This approach might mean more work > initially, though. Yes, indeed. I think Werner Koch had CC'd you the following message: http://lists.gnupg.org/pipermail/gnupg-users/2006-August/029125.html In particular, the issues raised in the thread above were: 1. You don't necessarily want to store your private key in a file or otherwise copy it in order to use it with GnuTLS. 2. Sometimes you can't even export your private key, for instance when it's stored in a smartcard that doesn't provide this operation. Thanks, Ludovic. From ludovic.courtes at laas.fr Fri Oct 27 14:31:00 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 27 Oct 2006 14:31:00 +0200 Subject: [Help-gnutls] Small inconsistencies of the OpenPGP API Message-ID: <87bqnygcu3.fsf@laas.fr> Hi, `gnutls_openpgp_key_get_pk_algorithm ()' currently returns an `int' while it should really return `gnutls_pk_algorithm_t'. Same for `privkey_get_pk_algorithm ()'. Also, `key_get_name ()' assumes that SIZEOF_BUF points to the size of BUF when it is invoked and uses that information to avoid buffer overflows; however, it does not modify *SIZEOF_BUF as one would expect to indicate the actual length of the name returned on success. Conversely, `key_get_fingerprint ()' does not take into account the initial value of *FPRLEN (thus, it may write data past the end of FPR) but it does modify it on return to indicate the actual length of the fingerprint returned. I think it would be best to both take into account the original value of these arguments _and_ modify them upon return to indicate the actual length of the element returned in both cases. Thanks, Ludovic. From jas at extundo.com Mon Oct 30 10:17:36 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon, 30 Oct 2006 10:17:36 +0100 Subject: [Help-gnutls] Re: Generating an RSA key In-Reply-To: <200610201511.47211.bradh@frogmouth.net> (Brad Hards's message of "Fri\, 20 Oct 2006 15\:11\:34 +1000") References: <200610201511.47211.bradh@frogmouth.net> Message-ID: <87slh640y7.fsf@latte.josefsson.org> Brad Hards writes: > I'm trying to write some code that generates RSA keys (given either the raw > parameters, and also given the exponent and bit size), and then extract > various things (bit size, public key), and some I/O in DER and PEM formats. > > I'd prefer it if I could avoid learning the sexp stuff used in libgcrypt. > However I can't find the right part of the API. > > Does anyone have a suggestion or example code that they would be willing to > share? Hi! I'm not aware of any code that does exactly what you want, although look in lib/x509/privkey.c for some functions that converts to and from raw RSA keys to PKCS#1 format. In particular, perhaps gnutls_x509_privkey_export_rsa_raw() and gnutls_x509_privkey_import_rsa_raw() does something similar to what you want? To generate the key, you can use gnutls_x509_privkey_generate() as a basis for your code, and replace the call to _gnutls_rsa_generate_params() with a call to your own function that generates the same values. They use the libgcrypt mpi_t type, but you wouldn't have to use the sexp stuff. Just some ideas.. /Simon From jas at extundo.com Mon Oct 30 10:31:05 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon, 30 Oct 2006 10:31:05 +0100 Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key In-Reply-To: <87wt6mkt3b.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Fri\, 27 Oct 2006 11\:26\:16 +0200") References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org> <87wt6mkt3b.fsf@laas.fr> Message-ID: <87odru40bq.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> ludovic.courtes at laas.fr (Ludovic Court?s) writes: >> >>> Hi, >>> >>> I tried importing the ASCII-armored OpenPGP secret key available under >>> `src/openpgp/sec.asc' as follows: >>> >>> err = gnutls_openpgp_privkey_import (privkey, &key_content, >>> GNUTLS_OPENPGP_FMT_BASE64, >>> "" /* empty passphrase */, >>> 0 /* flags? */); >>> >>> It systematically returns `GNUTLS_E_OPENPGP_GETKEY_FAILED'. This is >>> actually the exact same problem that I reported a while back [0]. Could >>> you please comment on this? >> >> Hi Ludovic, I'm sorry for the slow response. >> >> It is probably a bug in OpenCDK. Your best bet is to debug this >> further yourself, like using gdb to find where the error is triggered, >> and possibly try to guess why it happens and how to fix it. > > Looking at `cdk_pkt_read ()' (which is used by > `cdk_keydb_get_keyblock ()', which in turn is called by > `gnutls_openpgp_privkey_import ()') allowed me to guess that CDK > actually expects _binary_ private keys and not ASCII-armored keys. > > Thus, I tried passing it a private key produced by: > > $ gpg --export-secret-key THE-KEY > > and importing it does indeed work. Ah. I have some vague recollection that this has been mentioned before, so it may be a known bug. > This can be seen as a GnuTLS bug since the FORMAT argument of > `gnutls_openpgp_privkey_import' is not honored. Does CDK provide a way > to import ASCII-armored private keys? Otherwise, `privkey_import' > should return `UNIMPLEMENTED_FEATURE' when FORMAT is not `RAW'. I agree. There is code in OpenCDK to decode ASCII-armored data, so I suspect there is some minor bug that prevents this from working. Maybe you could single-step `gnutls_openpgp_privkey_import' to find out why it doesn't work? The function seem to eventually call _gnutls_openpgp_raw_privkey_to_gkey, which in the docstring claims to be able to read both BASE64 and RAW keys, so maybe you could even start debugging that function. > BTW, is there an API documentation for OpenCDK? Some of the function > names are self-explanatory, but some are not. In particular, I don't > understand the `keydb' in `cdk_keydb_get_keyblock'. Have you seen ? Although that particular function doesn't seem to be documented there... The keydb seem to be the output parameter, compare code in gnutls_openpgp.c: cdk_keydb_get_keyblock (out, &snode); if (!snode) ... pkt = cdk_kbnode_find_packet (snode, CDK_PKT_SECRET_KEY); if (!pkt) ... I'm not an OpenCDK expert, so you might know as much as I do on this. Please debug as much as possible and submit improved documentation based on what you find out! >> I don't think it has anything to do with remote servers, which you >> suggested in your last post -- there is no such functionality in >> GnuTLS/OpenCDK as far as I know. > > I was wondering what `GETKEY_FAILED' could really mean. From my current > understanding, it seems that `IMPORT_FAILED' would be more appropriate. GETKEY_FAILED seem to be a general "no such key" error. >> We could also consider if OpenCDK is the best option here, or whether >> it is possible to somehow use GnuPG instead. Using gpg might have >> other good side effects, such as nice smart card integration, and >> better web-of-trust management. This approach might mean more work >> initially, though. > > Yes, indeed. I think Werner Koch had CC'd you the following message: > > http://lists.gnupg.org/pipermail/gnupg-users/2006-August/029125.html > > In particular, the issues raised in the thread above were: > > 1. You don't necessarily want to store your private key in a file or > otherwise copy it in order to use it with GnuTLS. > > 2. Sometimes you can't even export your private key, for instance when > it's stored in a smartcard that doesn't provide this operation. I agree with both. The only problem is finding time and resources to work on implementing a change... If you have a strong interested in this, feel free to contact me privately and I can offer a price quote to work on achieving something in this area. Of course, if you want to work on this yourself, I'd be happy to discuss how to do this and review and install patches. /Simon From jas at extundo.com Mon Oct 30 13:41:38 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon, 30 Oct 2006 13:41:38 +0100 Subject: [Help-gnutls] Re: Small inconsistencies of the OpenPGP API In-Reply-To: <87bqnygcu3.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Fri\, 27 Oct 2006 14\:31\:00 +0200") References: <87bqnygcu3.fsf@laas.fr> Message-ID: <87ejsq0yd9.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > `gnutls_openpgp_key_get_pk_algorithm ()' currently returns an `int' > while it should really return `gnutls_pk_algorithm_t'. Same for > `privkey_get_pk_algorithm ()'. Hi! Thanks, fixed in CVS. > Also, `key_get_name ()' assumes that SIZEOF_BUF points to the size of > BUF when it is invoked and uses that information to avoid buffer > overflows; however, it does not modify *SIZEOF_BUF as one would expect > to indicate the actual length of the name returned on success. Fixed too, but please verify that it works OK. > Conversely, `key_get_fingerprint ()' does not take into account the > initial value of *FPRLEN (thus, it may write data past the end of FPR) > but it does modify it on return to indicate the actual length of the > fingerprint returned. Here the problem is that cdk_pk_get_fingerprint doesn't take a length parameter. I think a better solution here is to simply require that key_get_fingerprint must get a buffer of at least 20 bytes in size. Otherwise we would change the OpenCDK API/ABI, and that seems unwarranted here. Fixed in CVS now. > I think it would be best to both take into account the original value of > these arguments _and_ modify them upon return to indicate the actual > length of the element returned in both cases. Right, although API/ABI concerns may trump this, I think. Thanks, Simon From daniel at haxx.se Tue Oct 31 09:03:39 2006 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 31 Oct 2006 09:03:39 +0100 (CET) Subject: [Help-gnutls] avoiding signals completely Message-ID: Hi gnutls hackers! I want to be able to use GnuTLS without ever having to bother with signals! We're using GnuTLS within libcurl and lots of people use it multi-threaded and then signals don't work properly and make no sense. Within libcurl itself we then make an effort to avoid them all over, but now we've fallen over a problem when GnuTLS sends (or rather is the cause of) a SIGPIPE. I've checked the _gnutls_io_write_buffered() function in both 1.4.4 and 1.5.3 and there doesn't seem to be any means to disable the signal-generation. May I suggest that we at least add an option that avoids signals when using GnuTLS? It would be a matter of using the fourth send() argument on most platforms, and the SO_NOSIGPIPE socket option on some. We already do this magic in libcurl. I would be willing to provide a patch if there's no major objections. Here's the full backtrace from Brendan Jurd who faced this problem: http://curl.haxx.se/mail/lib-2006-10/0321.html From rks at mur.at Tue Oct 31 09:21:57 2006 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Tue, 31 Oct 2006 09:21:57 +0100 Subject: [Help-gnutls] avoiding signals completely In-Reply-To: References: Message-ID: <454707A5.4010102@mur.at> Daniel Stenberg schrieb: > Hi gnutls hackers! > > I want to be able to use GnuTLS without ever having to bother with signals! > > We're using GnuTLS within libcurl and lots of people use it > multi-threaded and then signals don't work properly and make no sense. > Within libcurl itself we then make an effort to avoid them all over, but > now we've fallen over a problem when GnuTLS sends (or rather is the > cause of) a SIGPIPE. > > I've checked the _gnutls_io_write_buffered() function in both 1.4.4 and > 1.5.3 and there doesn't seem to be any means to disable the > signal-generation. > > May I suggest that we at least add an option that avoids signals when > using GnuTLS? It would be a matter of using the fourth send() argument > on most platforms, and the SO_NOSIGPIPE socket option on some. We > already do this magic in libcurl. > > I would be willing to provide a patch if there's no major objections. > > Here's the full backtrace from Brendan Jurd who faced this problem: > > http://curl.haxx.se/mail/lib-2006-10/0321.html > > Why not simply disable SIGPIPE for the whole application with sigaction()? Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria From daniel at haxx.se Tue Oct 31 09:29:18 2006 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 31 Oct 2006 09:29:18 +0100 (CET) Subject: [Help-gnutls] avoiding signals completely In-Reply-To: <454707A5.4010102@mur.at> References: <454707A5.4010102@mur.at> Message-ID: On Tue, 31 Oct 2006, Rupert Kittinger-Sereinig wrote: >> May I suggest that we at least add an option that avoids signals when using >> GnuTLS? It would be a matter of using the fourth send() argument on most >> platforms, and the SO_NOSIGPIPE socket option on some. We already do this >> magic in libcurl. > > Why not simply disable SIGPIPE for the whole application with sigaction()? Yes, that's one way to do it for an application. But that's not a solution for a library and I want the library (libcurl) to work as documented without having to force the application to do various tricks. sigaction() is not even present everywhere. From rks at mur.at Tue Oct 31 09:47:51 2006 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Tue, 31 Oct 2006 09:47:51 +0100 Subject: [Help-gnutls] avoiding signals completely In-Reply-To: References: <454707A5.4010102@mur.at> Message-ID: <45470DB7.1070403@mur.at> Daniel Stenberg schrieb: > On Tue, 31 Oct 2006, Rupert Kittinger-Sereinig wrote: > >>> May I suggest that we at least add an option that avoids signals when >>> using GnuTLS? It would be a matter of using the fourth send() >>> argument on most platforms, and the SO_NOSIGPIPE socket option on >>> some. We already do this magic in libcurl. >> >> Why not simply disable SIGPIPE for the whole application with >> sigaction()? > > Yes, that's one way to do it for an application. But that's not a > solution for a library and I want the library (libcurl) to work as > documented without having to force the application to do various tricks. > sigaction() is not even present everywhere. well, signal(SIGPIPE, SIG_IGN) should be enough for everyone :-) generally, I think raising SIGPIPE with the default action to terminate the app was a terrible design decision, but a library like gnutls that simply takes a file descriptor should use the socket "as-is", and leave the rest to the client of the library. cheers, Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria From jas at extundo.com Tue Oct 31 15:38:15 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 31 Oct 2006 15:38:15 +0100 Subject: [Help-gnutls] Re: avoiding signals completely In-Reply-To: (Daniel Stenberg's message of "Tue\, 31 Oct 2006 09\:03\:39 +0100 \(CET\)") References: Message-ID: <87iri0sg88.fsf@latte.josefsson.org> Daniel Stenberg writes: > Hi gnutls hackers! > > I want to be able to use GnuTLS without ever having to bother with signals! > > We're using GnuTLS within libcurl and lots of people use it > multi-threaded and then signals don't work properly and make no > sense. Within libcurl itself we then make an effort to avoid them all > over, but now we've fallen over a problem when GnuTLS sends (or rather > is the cause of) a SIGPIPE. > > I've checked the _gnutls_io_write_buffered() function in both 1.4.4 > and 1.5.3 and there doesn't seem to be any means to disable the > signal-generation. > > May I suggest that we at least add an option that avoids signals when > using GnuTLS? It would be a matter of using the fourth send() argument > on most platforms, and the SO_NOSIGPIPE socket option on some. We > already do this magic in libcurl. Hi! I believe the design here is that GnuTLS should use the socket and the send function as-is, and if that isn't acceptable, you can write a replacement for send (which may simply be a dummy function that call send with an additional flag) and tell GnuTLS to use it by calling gnutls_transport_set_push_function. So you can achieve what you want today by using these hooks. An API to set the fourth parameter to send might be acceptable; I'm thinking something like: gnutls_transport_set_send_flags (gnutls_session_t session, int flags); Where the FLAGS variable would be used instead of 0 inside _gnutls_io_write_buffered. The variable should be 0 by default. Some send flags have weird semantics, though, so the documentation for the function would have to be clear on that, and should probably suggest that the only known reasonable use of the function is for MSG_NOSIGNAL. However, setting socket options inside GnuTLS seems like a bad idea. I believe the only POSIX dependency in libgnutls is for send and recv (which can be replaced), and we don't want more POSIX dependencies. > I would be willing to provide a patch if there's no major objections. > > Here's the full backtrace from Brendan Jurd who faced this problem: > > http://curl.haxx.se/mail/lib-2006-10/0321.html It seems as if the right solution, when CURLOPT_NOSIGNAL is present, would be for curl to set the socket options and to provide its own send replacement for GnuTLS, which would call send with the MSG_NOSIGNAL flag. Alternatively, the application could deal with SIGPIPE. /Simon From daniel at haxx.se Tue Oct 31 22:48:25 2006 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 31 Oct 2006 22:48:25 +0100 (CET) Subject: [Help-gnutls] Re: avoiding signals completely In-Reply-To: <87iri0sg88.fsf@latte.josefsson.org> References: <87iri0sg88.fsf@latte.josefsson.org> Message-ID: On Tue, 31 Oct 2006, Simon Josefsson wrote: > Hi! I believe the design here is that GnuTLS should use the socket and the > send function as-is, and if that isn't acceptable, you can write a > replacement for send (which may simply be a dummy function that call send > with an additional flag) and tell GnuTLS to use it by calling > gnutls_transport_set_push_function. So you can achieve what you want today > by using these hooks. Aha, I hadn't paid enough attention and gnutls_transport_set_push_function() had slipped my mind. Thanks a lot for pointing it out to me. I guess this also makes GnuTLS totally ignore the socket I set to it with gnutls_transport_set_ptr() so that I can instead pass my own private struct to the callback by using that function (I mean if I change both push and pull)?