From dragonheart at gentoo.org Sun May 1 06:20:46 2005 From: dragonheart at gentoo.org (Daniel) Date: Sun, 01 May 2005 14:20:46 +1000 Subject: [Help-gnutls] gnutls 1.2.3 type conflicts Message-ID: As reported in: http://bugs.gentoo.org/show_bug.cgi?id=90976 gnutls-1.2.3 fails under the following condition: ./configure --disable-openpgp-authentication --without-included-minilzo --without-included-libtasn1 --without-included-opencdk --with-zlib By trying other options the --disable-openpgp-authentication seems to be the cause. The output after the above configure line is: then mv -f ".deps/gnutls_buffers.Tpo" ".deps/gnutls_buffers.Plo"; else rm -f ".deps/gnutls_buffers.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../crypto -I../gl -I../includes -I../includes -I./x509 -I../libextra -I../libextra/openpgp/ -I../libextra/opencdk -I./minitasn1 -D_REENTRANT -D_THREAD_SAFE -pipe -MT gnutls_buffers.lo -MD -MP -MF .deps/gnutls_buffers.Tpo -c gnutls_buffers.c -fPIC -DPIC -o .libs/gnutls_buffers.o gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../crypto -I../gl -I../includes -I../includes -I./x509 -I../libextra -I../libextra/openpgp/ -I../libextra/opencdk -I./minitasn1 -D_REENTRANT -D_THREAD_SAFE -pipe -MT gnutls_buffers.lo -MD -MP -MF .deps/gnutls_buffers.Tpo -c gnutls_buffers.c -o gnutls_buffers.o >/dev/null 2>&1 if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../crypto -I../gl -I../includes -I../includes -I./x509 -I../libextra -I../libextra/openpgp/ -I../libextra/opencdk -I./minitasn1 -D_REENTRANT -D_THREAD_SAFE -pipe -MT gnutls_handshake.lo -MD -MP -MF ".deps/gnutls_handshake.Tpo" -c -o gnutls_handshake.lo gnutls_handshake.c; \ then mv -f ".deps/gnutls_handshake.Tpo" ".deps/gnutls_handshake.Plo"; else rm -f ".deps/gnutls_handshake.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../crypto -I../gl -I../includes -I../includes -I./x509 -I../libextra -I../libextra/openpgp/ -I../libextra/opencdk -I./minitasn1 -D_REENTRANT -D_THREAD_SAFE -pipe -MT gnutls_handshake.lo -MD -MP -MF .deps/gnutls_handshake.Tpo -c gnutls_handshake.c -fPIC -DPIC -o .libs/gnutls_handshake.o In file included from auth_cert.h:31, from gnutls_handshake.c:45: ../libextra/openpgp/openpgp.h:95: error: conflicting types for 'gnutls_openpgp_key_t' ../includes/gnutls/gnutls.h:597: error: previous declaration of 'gnutls_openpgp_key_t' was here ../libextra/openpgp/openpgp.h:96: error: conflicting types for 'gnutls_openpgp_privkey_t' ../includes/gnutls/gnutls.h:600: error: previous declaration of 'gnutls_openpgp_privkey_t' was here gnutls_handshake.c: In function `check_server_params': gnutls_handshake.c:2405: warning: initialization discards qualifiers from pointer target type gnutls_handshake.c:2431: warning: initialization discards qualifiers from pointer target type gnutls_handshake.c: In function `_gnutls_remove_unwanted_ciphersuites': gnutls_handshake.c:2488: warning: assignment discards qualifiers from pointer target type make[3]: *** [gnutls_handshake.lo] Error 1 make[3]: Leaving directory `/tmp/gnutls-1.2.3/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/gnutls-1.2.3/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnutls-1.2.3' make: *** [all] Error 2 Differing definitions are: includes/gnutls/gnutls.h: typedef struct gnutls_openpgp_key_int *gnutls_openpgp_key_t; libextra/openpgp/openpgp.h:typedef void *gnutls_openpgp_key_t; and -- ./lib/gnutls_int.h:typedef int (*gnutls_openpgp_recv_key_func) (struct gnutls_session_int *, ./lib/gnutls_int.h- const unsigned char *keyfpr, ./lib/gnutls_int.h- unsigned int keyfpr_length, ./lib/gnutls_int.h- gnutls_datum_t *); -- ./includes/gnutls/extra.h:typedef int (*gnutls_openpgp_recv_key_func) (gnutls_session_t session, ./includes/gnutls/extra.h- const unsigned char *keyfpr, ./includes/gnutls/extra.h- unsigned int keyfpr_length, ./includes/gnutls/extra.h- gnutls_datum_t *key); Other typedefs may differ and I haven't traced the purpose of these differences. -- Daniel Black Gentoo Crypto/PPC/dev-embedded/Forensics/NetMon From nmav at gnutls.org Sun May 1 22:33:28 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 1 May 2005 22:33:28 +0200 Subject: [Help-gnutls] gnutls 1.2.3 type conflicts In-Reply-To: References: Message-ID: <200505012233.28553.nmav@gnutls.org> On Sunday 01 May 2005 06:20, Daniel wrote: > As reported in: > http://bugs.gentoo.org/show_bug.cgi?id=90976 > gnutls-1.2.3 fails under the following condition: > ./configure --disable-openpgp-authentication --without-included-minilzo > --without-included-libtasn1 --without-included-opencdk --with-zlib > By trying other options the --disable-openpgp-authentication seems to be > the cause. > The output after the above configure line is: [...] > .libs/gnutls_handshake.o In file included from auth_cert.h:31, > from gnutls_handshake.c:45: > ../libextra/openpgp/openpgp.h:95: error: conflicting types for > 'gnutls_openpgp_key_t' ../includes/gnutls/gnutls.h:597: error: previous [...] > Other typedefs may differ and I haven't traced the purpose of these > differences. Hello Daniel, A quick fix might be to delete the lines 95-98 in libextra/openpgp/openpgp.h. I'll check it further in the next days. Not however that when you use --disable-openpgp-authentication the --without-included-opencdk is not really needed since it is not used at all. Anyway why compile without the openpgp part? -- Nikos Mavrogiannopoulos From jas at extundo.com Sun May 1 23:24:12 2005 From: jas at extundo.com (Simon Josefsson) Date: Sun, 01 May 2005 23:24:12 +0200 Subject: [Help-gnutls] Re: gnutls 1.2.3 type conflicts In-Reply-To: (Daniel's message of "Sun, 01 May 2005 14:20:46 +1000") References: Message-ID: Daniel writes: > Differing definitions are: ... > Other typedefs may differ and I haven't traced the purpose of these differences. Hello! Thanks for noticing this, I believe I have fixed this in CVS. Please try it, or the 2005-05-02 snapshot later tonight from: http://josefsson.org/daily/gnutls/ I can roll a 0.2.4 with this in a few days if you want. The reason why this wasn't present earlier was that the public header files weren't included by the source code. So the compiler could never understand that there were prototype differences. That is obviously bad, but we only get to notice this now when the public header file is included from everywhere... Regards, Simon From dragonheart at gentoo.org Mon May 2 00:24:00 2005 From: dragonheart at gentoo.org (Daniel) Date: Mon, 02 May 2005 08:24:00 +1000 Subject: [Help-gnutls] Re: gnutls 1.2.3 type conflicts References: <200505012233.28553.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos wrote: > Hello Daniel, > A quick fix might be to delete the lines 95-98 in > libextra/openpgp/openpgp.h. > I'll check it further in the next days. Not however that when you use > --disable-openpgp-authentication the --without-included-opencdk is not > really needed since it is not used at all. Anyway why compile without the > openpgp part? This was an option that was in the Gentoo package management of gnutls. I can't remember why it was there and have since removed it as a workaround. Based on the bit of logic here I'm going to not give the end user the easy option to disable it. Simon - as for a 1.2.4 release - don't do it on my/Gentoo's account. I've got a good workaround that given Nikos thought may just stay perminate. I only have seen the impact when there is a --disable-openpgp-authentication configure option present. If there are further reaching implications of a runtime problem then I'm sure you will be pushing the release cycle forward and I'll take notice of that. Thanks again, Daniel Black Gentoo Crypto/PPC/dev-embedded/Forensics/NetMon From regit at inl.fr Tue May 3 10:38:08 2005 From: regit at inl.fr (Regit) Date: Tue, 03 May 2005 10:38:08 +0200 Subject: [Help-gnutls] GnuTLS 1.2.3 and 1.0.25 In-Reply-To: References: Message-ID: <1115109488.10690.8.camel@localhost.localdomain> Le jeudi 28 avril 2005 ? 13:06 +0200, Simon Josefsson a ?crit : > We do not have the resources to analyze and write an explanation of > this security problem. Volunteers who want to read the bug reports > and the CVS changes, and write up an explanation in plain English, are > most welcome! Having a detailed track record of security problems can > be a useful reference when discussing security in free software > packages in general. Hi, The problem was discovered by INL when we were studying a crash of nuauth, a daemon which is part of the NuFW project (http://www.nufw.org). During stress test we made on our solution, we open a lot of tls sessions simultaneously (more than 200). After some times the application crash with a segfault. I will try to write a detailed track record of this security problem : The problem occur in the _gnutls_ciphertext2compressed function which is called to deciphers the ciphertext packet and puts the result to compressed datas. It is mainly called in _gnutls_decrypt so it has to directly deal with user entries. The prototype of the function is as follow : int _gnutls_ciphertext2compressed(gnutls_session session, opaque* compress_data, int compress_size, gnutls_datum ciphertext, uint8 type) It is important to notice that ciphertext is an entry from the user. The length of ciphertext (ciphertext.size) is computed by _gnutls_check_record_headers. It is done by parsing the header of the recived packet. The problem occurs in the case CIPHER_BLOCK: beginning at line 450. I copy here under the important part of this code taken from the bug analysis point of view : case CIPHER_BLOCK: if ((ciphertext.size < blocksize) || (ciphertext.size % blocksize != 0)) { gnutls_assert(); ... /******************** * pad is computed with user datas so this can be set with any value we want. *********************/ pad = ciphertext.data[ciphertext.size - 1] + 1; /* pad */ length = ciphertext.size - hash_size - pad; /********************* * We do a coherence check here. Code use later the pad value as * a revert array index for ciphertext. So it is good to check * that we will not exit out of the array when iterating. * * But gnutls_assert is not an exit function so we continue * as specified in the comment. **********************/ if (pad > ciphertext.size - hash_size) { gnutls_assert(); /* We do not fail here. We check below for the * the pad_failed. If zero means success. */ pad_failed = GNUTLS_E_DECRYPTION_FAILED; } /* Check the pading bytes (TLS 1.x) */ /******************** * Here we are, we enter in the conditionnal even * if we fail before *********************/ if ( ver >= GNUTLS_TLS1 ) /******************* * We iterate over i with i < pad, but as we can have * pad > ciphertext.size this lead to a crash : * If pad > ciphertext.size code does when i = ciphertextsize+1 : * ciphertext.data[-1] * So code segfault *********************/ for (i=2;i Hi, I'm looking for the correct way to set a timeout to gnutls_handshake. I want to be able to say something like stop handshake after N seconds, so I will be able to free threads working on handshake. I don't want that a simple telnet on application port blocks the thread for an eternity. Any idea or tips welcome, BR, -- ?ric Leblond, eleblond at inl.fr T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr From regit at inl.fr Wed May 4 16:21:15 2005 From: regit at inl.fr (Regit) Date: Wed, 04 May 2005 16:21:15 +0200 Subject: [Help-gnutls] Re: Security advisories (was: Re: GnuTLS 1.2.3 and 1.0.25) In-Reply-To: References: <1115109488.10690.8.camel@localhost.localdomain> Message-ID: <1115216475.26791.17.camel@localhost.localdomain> Hi, > I'm not convinced the "Severity" column is useful. Judging the > severity might be rather subjective in some cases. Perhaps it will go > away. Someone point me to that page : http://www.vulnerabilite.com/cvss/ It's a scoring system for vulnerability. It might be useful as the criteria seems good. BR, -- ?ric Leblond, eleblond at inl.fr T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr From regit at inl.fr Wed May 4 20:44:18 2005 From: regit at inl.fr (Eric Leblond) Date: Wed, 04 May 2005 20:44:18 +0200 Subject: [Help-gnutls] gnutls_handshake and timeout Message-ID: <1115232259.5410.0.camel@porky> Hi, I'm looking for the correct way to set a timeout to gnutls_handshake. I want to be able to say something like stop handshake after N seconds, so I will be able to free threads working on handshake. I don't want that a simple telnet on application port blocks the thread for an eternity. Any idea or tips welcome, BR, -- ?ric Leblond, eleblond at inl.fr T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr From jas at extundo.com Wed May 4 15:16:30 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 04 May 2005 15:16:30 +0200 Subject: [Help-gnutls] Security advisories (was: Re: GnuTLS 1.2.3 and 1.0.25) In-Reply-To: <1115109488.10690.8.camel@localhost.localdomain> (regit@inl.fr's message of "Tue, 03 May 2005 10:38:08 +0200") References: <1115109488.10690.8.camel@localhost.localdomain> Message-ID: Regit writes: > The problem was discovered by INL when we were studying a crash of > nuauth, a daemon which is part of the NuFW project > (http://www.nufw.org). During stress test we made on our solution, we > open a lot of tls sessions simultaneously (more than 200). After some > times the application crash with a segfault. > > I will try to write a detailed track record of this security problem : Thanks a lot! I have created a page for security advisories: http://josefsson.org/gnutls/security.html Your DoS-problem is now called GNUTLS-SA-2005-1. I will add a link to your post once it is in the mailing list archive. If someone wants to add even more information, I can add more links. Everyone is encouraged to write up similar reports for future problems! An archive of reports, similar to yours, will be a very useful resource in a few years, as a reference for what kind security errors occur in the wild, how they are solved, how fast, etc. Having more eyes analyzing each bug would also be useful. So don't let the existence of one report stop you from separately looking into the bug and write up something. I'm not convinced the "Severity" column is useful. Judging the severity might be rather subjective in some cases. Perhaps it will go away. Regards, Simon From nmav at gnutls.org Wed May 4 23:20:01 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 May 2005 23:20:01 +0200 Subject: [Help-gnutls] gnutls_handshake and timeout In-Reply-To: <1115134358.10690.28.camel@localhost.localdomain> References: <1115134358.10690.28.camel@localhost.localdomain> Message-ID: <200505042320.02388.nmav@gnutls.org> On Tuesday 03 May 2005 17:32, Regit wrote: > Hi, > > I'm looking for the correct way to set a timeout to gnutls_handshake. I > want to be able to say something like stop handshake after N seconds, so > I will be able to free threads working on handshake. > I don't want that a simple telnet on application port blocks the thread > for an eternity. Hello, The only reason gnutls_handshake() blocks are the recv() and probably send() calls. You can set a timeout on these calls with setsockopt(). In that case gnutls_handshake() will return GNUTLS_E_AGAIN. Hope that helps. > BR, -- Nikos Mavrogiannopoulos From dan.trainor at gmail.com Tue May 24 00:05:15 2005 From: dan.trainor at gmail.com (dan) Date: Mon, 23 May 2005 15:05:15 -0700 Subject: [Help-gnutls] No entropy gathering module detected Message-ID: <4292539B.3070708@gmail.com> Good afternoon, all - I'm new to the list, I'd like to first thank the developers of GNUTLS for their fine work. We appreciate it. We're developing a threaded application in our development department, and it's going alright so far. However, we keep getting an error which we believe comes from generate_dh_params(). The error is as follows: Fatal: no entropy gathering module detected The most we've been able to gather using google.com and assorted resources is that entropy cannot be established. The only solution that we had found that was even remotely related to ours just suggested making sure that /dev/{u}random had world-readable permissions. Aside from that, we don't know what to go by. Any pointers? Thanks! -dant From jas at extundo.com Tue May 24 00:23:57 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 24 May 2005 00:23:57 +0200 Subject: [Help-gnutls] Re: No entropy gathering module detected In-Reply-To: <4292539B.3070708@gmail.com> (dan's message of "Mon, 23 May 2005 15:05:15 -0700") References: <4292539B.3070708@gmail.com> Message-ID: dan writes: > Good afternoon, all - > > I'm new to the list, I'd like to first thank the developers of GNUTLS > for their fine work. We appreciate it. > > We're developing a threaded application in our development department, > and it's going alright so far. However, we keep getting an error which > we believe comes from generate_dh_params(). The error is as follows: > > Fatal: no entropy gathering module detected > > The most we've been able to gather using google.com and assorted > resources is that entropy cannot be established. The only solution that > we had found that was even remotely related to ours just suggested > making sure that /dev/{u}random had world-readable permissions. Aside > from that, we don't know what to go by. > > Any pointers? That is a libgcrypt error. Check how you built libgcrypt. If the Win32/Linux/Unix RNG can't be used, you might need to run EGD. You could also try building GnuTLS with --with-nettle. Hope this helps, Simon From dan.trainor at gmail.com Tue May 24 02:06:04 2005 From: dan.trainor at gmail.com (dan) Date: Mon, 23 May 2005 17:06:04 -0700 Subject: [Help-gnutls] Re: No entropy gathering module detected In-Reply-To: References: <4292539B.3070708@gmail.com> Message-ID: <42926FEC.70605@gmail.com> Simon Josefsson wrote: > dan writes: > > >>Good afternoon, all - >> >>I'm new to the list, I'd like to first thank the developers of GNUTLS >>for their fine work. We appreciate it. >> >>We're developing a threaded application in our development department, >>and it's going alright so far. However, we keep getting an error which >>we believe comes from generate_dh_params(). The error is as follows: >> >>Fatal: no entropy gathering module detected >> >>The most we've been able to gather using google.com and assorted >>resources is that entropy cannot be established. The only solution that >>we had found that was even remotely related to ours just suggested >>making sure that /dev/{u}random had world-readable permissions. Aside >>from that, we don't know what to go by. >> >>Any pointers? > > > That is a libgcrypt error. Check how you built libgcrypt. If the > Win32/Linux/Unix RNG can't be used, you might need to run EGD. > > You could also try building GnuTLS with --with-nettle. > > Hope this helps, > Simon > Simon - Thanks for the response. The only argument we're compiling libgcrypt with is '--disable-asm'. I took the origional RPM for libgcrypt-1.2.0-1, and modified it slightly for -1.2.1, just in case. We get this error regardless of which version we're using. Why wouldn't we able to use the RNG on this Linux platform? What would prevent us? Thanks! -dant From rakesh at rebaca.com Wed May 25 16:17:12 2005 From: rakesh at rebaca.com (Rakesh Jain) Date: Wed, 25 May 2005 19:47:12 +0530 Subject: [Help-gnutls] WINCE porting Message-ID: <011f01c56134$739cd9a0$d300a8c0@rakesh> Hi, Is gnutls library ported on Windows CE platform? Thanks in advance. Regards, Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jas at extundo.com Wed May 25 16:28:04 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 25 May 2005 16:28:04 +0200 Subject: [Help-gnutls] Re: WINCE porting In-Reply-To: <011f01c56134$739cd9a0$d300a8c0@rakesh> (Rakesh Jain's message of "Wed, 25 May 2005 19:47:12 +0530") References: <011f01c56134$739cd9a0$d300a8c0@rakesh> Message-ID: "Rakesh Jain" writes: > Hi, > Is gnutls library ported on Windows CE platform? > Thanks in advance. Not that I know. It is simple C89 and POSIX, so should not be difficult to port. One concern may be libgcrypt portability. Cheers, Simon From jas at extundo.com Sat May 28 12:15:58 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 28 May 2005 12:15:58 +0200 Subject: [Help-gnutls] GnuTLS 1.2.4 Message-ID: We are pleased to announce the availability of GnuTLS 1.2.4! Noteworthy changes since version 1.2.3: - Corrected some bugs that could affect 64 bit systems. - Some corrections in the header files to include the prototype of memmem properly (affected 64 bit systems). Report and patch by Yoann Vandoorselaere . - Introduced the --fix-key option to certtool, which can be used to regenerate the (optional) parameters in a private key. It should be used together with --key-info. - Corrected a bug in certificate chain verification that could lead to marking a trusted chain as non trusted, if the last certificate in the chain was a self signed one. - Gnulib portability files were updated. - License were updated to reflect new FSF address. The NEWS file fail to mention it, but there are no API/ABI changes between 1.2.3 and 1.2.4. 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: http://josefsson.org/gnutls/releases/gnutls-1.2.4.tar.bz2 (2.4MB) ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.4.tar.bz2 (2.4MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.2.4.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.4.tar.bz2.sig Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the MD5/SHA1 checksums: 57f97e1544f19e986ea20d5180b013fd gnutls-1.2.4.tar.bz2 ae0d1c36c62ca558faaf4282b0f18bfd gnutls-1.2.4.tar.bz2.sig f54c9fe5aa11b3e4cb2109d29cf38d98d11c72dc gnutls-1.2.4.tar.bz2 9240d8c1dfac96027f9d528132e4402d366e4be8 gnutls-1.2.4.tar.bz2.sig Enjoy, Nikos and Simon From alangley at gmail.com Sat May 28 23:17:18 2005 From: alangley at gmail.com (Adam Langley) Date: Sat, 28 May 2005 22:17:18 +0100 Subject: [Help-gnutls] Announce: pyGnuTLS 0.1 Message-ID: <396556a205052814176cde9731@mail.gmail.com> pyGnuTLS is a Python wrapping of GnuTLS: http://www.imperialviolet.org/pygnutls.html See the README information on that page for more information. These wrappings are very similar to the python-gnutls ones: http://home.o2w.net/~ivo/python-gnutls/dist/ but I needed more functions and decided that it would be easier to start again and use Pyrex than to add to python-gnutls with C. They are already fairly complete for most uses. Significant areas have been omitted because I got bored: OpenPGP CRL CRQ SRP PKCS12 PKCS7 but these can be fairly quickly added in Pyrex if anyone has a need. AGL -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From jas at extundo.com Sun May 29 11:40:53 2005 From: jas at extundo.com (Simon Josefsson) Date: Sun, 29 May 2005 11:40:53 +0200 Subject: [Help-gnutls] Re: Announce: pyGnuTLS 0.1 In-Reply-To: <396556a205052814176cde9731@mail.gmail.com> (Adam Langley's message of "Sat, 28 May 2005 22:17:18 +0100") References: <396556a205052814176cde9731@mail.gmail.com> Message-ID: Adam Langley writes: > pyGnuTLS is a Python wrapping of GnuTLS: > http://www.imperialviolet.org/pygnutls.html Thanks, added to . From jas at extundo.com Sun May 29 12:09:16 2005 From: jas at extundo.com (Simon Josefsson) Date: Sun, 29 May 2005 12:09:16 +0200 Subject: [Help-gnutls] Re: No entropy gathering module detected In-Reply-To: <42926FEC.70605@gmail.com> (dan's message of "Mon, 23 May 2005 17:06:04 -0700") References: <4292539B.3070708@gmail.com> <42926FEC.70605@gmail.com> Message-ID: dan writes: > Simon Josefsson wrote: >> dan writes: >> >>>Good afternoon, all - >>> >>> I'm new to the list, I'd like to first thank the developers of >>> GNUTLS for their fine work. We appreciate it. >>> >>> We're developing a threaded application in our development >>> department, and it's going alright so far. However, we keep >>> getting an error which we believe comes from generate_dh_params(). >>> The error is as follows: >>> >>>Fatal: no entropy gathering module detected >>> >>> The most we've been able to gather using google.com and assorted >>> resources is that entropy cannot be established. The only solution >>> that we had found that was even remotely related to ours just >>> suggested making sure that /dev/{u}random had world-readable >>> permissions. Aside from that, we don't know what to go by. >>> >>>Any pointers? >> That is a libgcrypt error. Check how you built libgcrypt. If the >> Win32/Linux/Unix RNG can't be used, you might need to run EGD. >> You could also try building GnuTLS with --with-nettle. >> Hope this helps, >> Simon >> > > Simon - > > Thanks for the response. > > The only argument we're compiling libgcrypt with is '--disable-asm'. I > took the origional RPM for libgcrypt-1.2.0-1, and modified it slightly > for -1.2.1, just in case. We get this error regardless of which version > we're using. > > Why wouldn't we able to use the RNG on this Linux platform? What would > prevent us? I don't know, perhaps you can quote relevant parts of the output from libgcrypt's "configure" output? Does 'make check' in libgcrypt work? Perhaps some libgcrypt expert can help. Regards, Simon