From sfrost at snowman.net Sat Mar 6 08:19:31 2004 From: sfrost at snowman.net (Stephen Frost) Date: Sat, 6 Mar 2004 02:19:31 -0500 Subject: [gnutls-dev] Generating/regenerating params Message-ID: <20040306071931.GQ7060@ns.snowman.net> Greetings, I've run into a very difficult problem when trying to safely regenerate dh/rsa parameters. The setup is like this: There's a global context which has creds (gnutls_certificate_credentials) and all of the CA certs and whatnot are loaded into it. We then have a local (per thread) context which copies the cred from the global context, but just the pointer (there isn't a function to copy the whole thing...). We then set params in creds in each thread, cacheing the params in a file and regenerating the params whenever the file disappears, which we plan to make happen periodically as is recommended in various comments in the example GNU TLS server. There's a couple problems here though: The params are shared across all threads because of the single global context with creds. I worry about regenerating them because I don't want to break existing connections or ones which are in the process of setting up. I don't see any way (beyond re-reading all the certs which I expect would kill performance) to make the creds be local though. What's the right way to do this? Have multiple threads going and still periodically regenerate the rsa/dh params without breaking anything or leaking memory or anything? Is it safe to just init the rsa/dh params and then just change them with generate2 or import_raw? Will that break existing connections or other threads which are setting up their connections? Do I still need to call set_XX_params? Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Sun Mar 7 18:59:35 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 7 Mar 2004 19:59:35 +0200 Subject: [gnutls-dev] Generating/regenerating params In-Reply-To: <20040306071931.GQ7060@ns.snowman.net> References: <20040306071931.GQ7060@ns.snowman.net> Message-ID: <20040307175934.GA10135@gnutls.org> On Sat, Mar 06, 2004 at 02:19:31AM -0500, Stephen Frost wrote: > Greetings, > I've run into a very difficult problem when trying to safely > regenerate dh/rsa parameters. The setup is like this: > There's a global context which has creds > (gnutls_certificate_credentials) and all of the CA certs and whatnot > are loaded into it. > We then have a local (per thread) context which copies the cred from > the global context, but just the pointer (there isn't a function to > copy the whole thing...). There is no need to copy the whole thing, since the credentials are only read by the sessions. They are never modified. > We then set params in creds in each thread, cacheing the params in a > file and regenerating the params whenever the file disappears, which > we plan to make happen periodically as is recommended in various > comments in the example GNU TLS server. > There's a couple problems here though: The params are shared across > all threads because of the single global context with creds. I worry > about regenerating them because I don't want to break existing > connections or ones which are in the process of setting up. I don't > see any way (beyond re-reading all the certs which I expect would kill > performance) to make the creds be local though. > What's the right way to do this? Have multiple threads going and > still periodically regenerate the rsa/dh params without breaking > anything or leaking memory or anything? Is it safe to just init the > rsa/dh params and then just change them with generate2 or import_raw? > Will that break existing connections or other threads which are > setting up their connections? Do I still need to call set_XX_params? Currently there is no easy way to renew that parameters in multithreaded applications. I was thinking into adding functions or callbacks to set those parameters per session. Would this solve your problem? > Thanks, > Stephen -- Nikos Mavroyanopoulos From sfrost at snowman.net Tue Mar 9 13:52:15 2004 From: sfrost at snowman.net (Stephen Frost) Date: Tue, 9 Mar 2004 07:52:15 -0500 Subject: [gnutls-dev] Generating/regenerating params In-Reply-To: <20040307175934.GA10135@gnutls.org> References: <20040306071931.GQ7060@ns.snowman.net> <20040307175934.GA10135@gnutls.org> Message-ID: <20040309125214.GW7060@ns.snowman.net> * Nikos Mavroyanopoulos (nmav at gnutls.org) wrote: > On Sat, Mar 06, 2004 at 02:19:31AM -0500, Stephen Frost wrote: > > We then have a local (per thread) context which copies the cred from > > the global context, but just the pointer (there isn't a function to > > copy the whole thing...). > There is no need to copy the whole thing, since the credentials > are only read by the sessions. They are never modified. Sure, but if I could make the creds structure local to each thread I'd solve the param generation problem. > > What's the right way to do this? Have multiple threads going and > > still periodically regenerate the rsa/dh params without breaking > > anything or leaking memory or anything? Is it safe to just init the > > rsa/dh params and then just change them with generate2 or import_raw? > > Will that break existing connections or other threads which are > > setting up their connections? Do I still need to call set_XX_params? > > Currently there is no easy way to renew that parameters in multithreaded > applications. I was thinking into adding functions or callbacks to set those > parameters per session. Would this solve your problem? I *think* I've stumbled across a reasonable solution for the moment. From what I can tell, params are only used during setup/handshake. What I've done is basically lock around the setup/handshake routine and just generate/reread/cache the params before setup/handshake and then free them after. There's currently no function to free the params when they're stored inside the credentials structure so I have to track the params pointers seperately (not that big a deal since they're only needed through one function which does the setup/handshake, but it'd be nice if there was way to free *just* the params in the credentials struct). Do you see any problem with this approach? BTW: I'm not too inclined to agree with the 'thread-safe' feature claim on the webpage. :) Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Tue Mar 9 18:38:53 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 9 Mar 2004 19:38:53 +0200 Subject: [gnutls-dev] Generating/regenerating params In-Reply-To: <20040309125214.GW7060@ns.snowman.net> References: <20040306071931.GQ7060@ns.snowman.net> <20040307175934.GA10135@gnutls.org> <20040309125214.GW7060@ns.snowman.net> Message-ID: <20040309173853.GA4966@gnutls.org> On Tue, Mar 09, 2004 at 07:52:15AM -0500, Stephen Frost wrote: > > > What's the right way to do this? Have multiple threads going and > > > still periodically regenerate the rsa/dh params without breaking > > > anything or leaking memory or anything? Is it safe to just init the > > > rsa/dh params and then just change them with generate2 or import_raw? > > > Will that break existing connections or other threads which are > > > setting up their connections? Do I still need to call set_XX_params? > > Currently there is no easy way to renew that parameters in multithreaded > > applications. I was thinking into adding functions or callbacks to set those > > parameters per session. Would this solve your problem? > I *think* I've stumbled across a reasonable solution for the moment. > From what I can tell, params are only used during setup/handshake. What > I've done is basically lock around the setup/handshake routine and just > generate/reread/cache the params before setup/handshake and then free > them after. There's currently no function to free the params when > they're stored inside the credentials structure so I have to track the > params pointers seperately (not that big a deal since they're only > needed through one function which does the setup/handshake, but it'd be > nice if there was way to free *just* the params in the credentials > struct). You don't have too free them there, since only a pointer is stored. I'll update that api in the next gnutls development release, so that parameters could be obtained on the fly (using a callback or something). > Do you see any problem with this approach? It should work. > BTW: I'm not too inclined to agree with the 'thread-safe' feature claim > on the webpage. :) Why is that? > Stephen -- Nikos Mavroyanopoulos From papadopo at shfj.cea.fr Mon Mar 15 15:35:17 2004 From: papadopo at shfj.cea.fr (Dimitri Papadopoulos-Orfanos) Date: Mon, 15 Mar 2004 15:35:17 +0100 Subject: [gnutls-dev] Re: building opencdk-0.5.4 on Solaris 8 In-Reply-To: <4055B949.80407@shfj.cea.fr> References: <4055B949.80407@shfj.cea.fr> Message-ID: <4055BF25.7040900@shfj.cea.fr> Hi again, > About the getpass() issue, is already included but a macro > needs to be defined: > [...] > Adding: > #define __EXTENSIONS__ > works but I have no clue why it would needed on Solaris. Mmmh... It would seem getpass() is considered a legacy or deprecated function: http://www.opengroup.org/onlinepubs/007908799/xsh/getpass.html http://www.mkssoftware.com/docs/man3/getpass.3.asp and is actually missing from Single Unix Specification version 3: http://www.opengroup.org/onlinepubs/007904975/basedefs/unistd.h.html See also: http://sources.redhat.com/ml/libc-alpha/2003-05/msg00240.html http://www.gnu.org/software/libc/manual/html_node/getpass.html#getpass It's probably better not to use getpass(). Regards, -- Dimitri Papadopoulos From papadopo at shfj.cea.fr Mon Mar 15 15:21:11 2004 From: papadopo at shfj.cea.fr (Dimitri Papadopoulos-Orfanos) Date: Mon, 15 Mar 2004 15:21:11 +0100 Subject: [gnutls-dev] building gnutls-1.0.8 on Solaris 8: failure Message-ID: <4055BBD7.30308@shfj.cea.fr> Hi, GnuTLS 1.0.8 fails to build on my Solaris 8 machine. The reason is that the OpenCDK header inclusion path is missing: /bin/bash ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I../libextra -Iminitasn1/ -I../includes -I/usr/local/libgcrypt/include -I/usr/local/libgpg-error/include -O -D_REENTRANT -D_THREAD_SAFE -I/usr/local/libgcrypt/include -I/usr/local/libgpg-error/include -c -o gnutls_handshake.lo `test -f 'gnutls_handshake.c' || echo './'`gnutls_handshake.c cc -DHAVE_CONFIG_H -I. -I. -I.. -I../libextra -Iminitasn1/ -I../includes -I/usr/local/libgcrypt/include -I/usr/local/libgpg-error/include -O -D_REENTRANT -D_THREAD_SAFE -I/usr/local/libgcrypt/include -I/usr/local/libgpg-error/include -c gnutls_handshake.c -KPIC -DPIC -o .libs/gnutls_handshake.o "../libextra/openpgp/openpgp.h", line 12: cannot find include file: "../libextra/openpgp/openpgp.h", line 15: syntax error before or at: cdk_kbnode_t "../libextra/openpgp/openpgp.h", line 15: cannot recover from previous errors cc: acomp failed for gnutls_handshake.c It's missing a -I/usr/local/opencdk/include. On my system: $ opencdk-config --cflags -I/usr/local/libgcrypt/include -I/usr/local/libgpg-error/include -I/usr/local/opencdk/include $ I know this is a peculiar and unusual installation, but still, that should probably be fixed. There are also warnings I'll report in another mail. Regards, -- Dimitri Papadopoulos From nmav at gnutls.org Mon Mar 15 16:39:58 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon, 15 Mar 2004 17:39:58 +0200 Subject: [gnutls-dev] Re: building opencdk-0.5.4 on Solaris 8 In-Reply-To: <4055BF25.7040900@shfj.cea.fr> References: <4055B949.80407@shfj.cea.fr> <4055BF25.7040900@shfj.cea.fr> Message-ID: <20040315173958.22c61759.nmav@gnutls.org> On Mon, 15 Mar 2004 15:35:17 +0100 Dimitri Papadopoulos-Orfanos wrote: > Hi again, > > About the getpass() issue, is already included but a macro > > needs to be defined: > > [...] > > Adding: > > #define __EXTENSIONS__ > > works but I have no clue why it would needed on Solaris. > Mmmh... It would seem getpass() is considered a legacy or deprecated > function: [...] > It's probably better not to use getpass(). I'll replace it with something better in the next release. > Regards, > -- > Dimitri Papadopoulos -- Nikos Mavroyanopoulos From nmav at gnutls.org Tue Mar 30 12:06:43 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 30 Mar 2004 13:06:43 +0300 Subject: [gnutls-dev] gnutls 1.0.9 Message-ID: <200403301306.43100.nmav@gnutls.org> I've just released gnutls 1.0.9. The changes since the last release are: - Added gnutls_certificate_set_params_function() and gnutls_anon_set_params_function() that set the RSA or DH parameters using a callback. - Added functions gnutls_rsa_params_cpy(), gnutls_dh_params_cpy() and gnutls_x509_privkey_cpy(). - Corrected a compilation issue when opencdk was installed in a non standard directory. - Documented the changes need in multi-threaded application due to the new libgcrypt. Note that the new libgcrypt changes the way it handled multi-threaded applications. See the 'multi-threaded applications' section of the manual, and the libgcrypt manual for more information. -- Nikos Mavroyanopoulos