From simon at josefsson.org  Mon Apr 16 09:43:04 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 09:43:04 +0200
Subject: Assertion failure advice
In-Reply-To: <evrlem$lit$1@sea.gmane.org> (David Given's message of "Sat\, 14
	Apr 2007 23\:50\:27 +0100")
References: <evrlem$lit$1@sea.gmane.org>
Message-ID: <87abx8ojcn.fsf@mocca.josefsson.org>

David Given <dg at cowlark.com> writes:

> My program, which uses gnutls, is very occasionally crashing for no apparent
> reason. After much effort (running it in a screen session for two weeks...)
> I've finally managed to get some tracing:

Thanks for debugging this.

> spey: ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)'
> failed.
>
> This appears to be an assertion failure inside gnutls. I can tell from the
> rest of the tracing that it's happening inside a call to gnutls_handshake().

This looks like a gcrypt and mutex related problem to me.  I'm cc'ing
the libgcrypt mailing list.  Werner, any ideas?  What would trigger
this assertion?

> Does anyone know what this might be signifying? It doesn't seem to be my
> fault, but I have had very little experience driving the GNUTLS API and I
> could easily be getting something wrong. It looks like a mutex failure, but
> while my program is multithreaded, I'm using a unique session object per
> socket, so I wouldn't have thought this would apply.

Does you program link to libgcrypt through some other dependency?
Think LDAP, etc.  Do you initialize libgcrypt/gnutls with mutexes?

/Simon


From wk at gnupg.org  Mon Apr 16 11:36:38 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Apr 2007 11:36:38 +0200
Subject: Assertion failure advice
In-Reply-To: <87abx8ojcn.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon\, 16 Apr 2007 09\:43\:04 +0200")
References: <evrlem$lit$1@sea.gmane.org> <87abx8ojcn.fsf@mocca.josefsson.org>
Message-ID: <87bqho8xuh.fsf@wheatstone.g10code.de>

On Mon, 16 Apr 2007 09:43, simon at josefsson.org said:

>> spey: ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)'
>
> This looks like a gcrypt and mutex related problem to me.  I'm cc'ing
> the libgcrypt mailing list.  Werner, any ideas?  What would trigger
> this assertion?

The thread callbacks are not setup at time.  This should be done even
before the version check and definitely before initializing secure
memory.  Here is an example using GNU Pth:

  /* Libgcrypt requires us to register the threading model first.
     Note that this will also do the pth_init. */
  err = gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pth);
  if (err)
    {
      log_fatal ("can't register GNU Pth with Libgcrypt: %s\n",
                 gpg_strerror (err));
    }

  /* Check that the libraries are suitable.  Do it here because
     the option parsing may need services of the library */
  if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) )
    {
      log_fatal( _("libgcrypt is too old (need %s, have %s)\n"),
                 NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) );
    }

Now continue with any other init stuff.  The manual explains this
http://www.gnupg.org/documentation/manuals/gcrypt/Multi-Threading.html



Salam-Shalom,

   Werner



From simon at josefsson.org  Tue Apr 17 10:47:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Apr 2007 10:47:13 +0200
Subject: Assertion failure advice
In-Reply-To: <f011ro$3od$1@sea.gmane.org> (David Given's message of "Tue\, 17
	Apr 2007 00\:46\:59 +0100")
References: <evrlem$lit$1@sea.gmane.org> <87abx8ojcn.fsf@mocca.josefsson.org>
	<87bqho8xuh.fsf@wheatstone.g10code.de> <f011ro$3od$1@sea.gmane.org>
Message-ID: <87y7kr1j72.fsf@mocca.josefsson.org>

David Given <dg at cowlark.com> writes:

> Werner Koch wrote:
> [...]
>> The thread callbacks are not setup at time.  This should be done even
>> before the version check and definitely before initializing secure
>> memory.  Here is an example using GNU Pth:
>
> I've just noticed that there's a section of the gnutls manual calling
> 'Multithreaded programs' which, er, I'd completely missed the first time
> through. Which means that I haven't been telling gnutls to set up gcrypt
> properly. Mea culpa; sorry.
>
> Presumably I'm only getting this crash when two threads try to do a TLS
> handshake at the same time, at exactly the right time to cause gcrypt to step
> on its own toes.
>
> I'll fix this and see if the problem goes away.

Good.  It was good to know what error is likely to come up if you
forget to initialize threading properly.  Thanks again for reporting,
and let us know how it works out.

/Simon


From dg at cowlark.com  Tue Apr 17 01:46:59 2007
From: dg at cowlark.com (David Given)
Date: Tue, 17 Apr 2007 00:46:59 +0100
Subject: Assertion failure advice
In-Reply-To: <87bqho8xuh.fsf@wheatstone.g10code.de>
References: <evrlem$lit$1@sea.gmane.org> <87abx8ojcn.fsf@mocca.josefsson.org>
	<87bqho8xuh.fsf@wheatstone.g10code.de>
Message-ID: <f011ro$3od$1@sea.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Werner Koch wrote:
[...]
> The thread callbacks are not setup at time.  This should be done even
> before the version check and definitely before initializing secure
> memory.  Here is an example using GNU Pth:

I've just noticed that there's a section of the gnutls manual calling
'Multithreaded programs' which, er, I'd completely missed the first time
through. Which means that I haven't been telling gnutls to set up gcrypt
properly. Mea culpa; sorry.

Presumably I'm only getting this crash when two threads try to do a TLS
handshake at the same time, at exactly the right time to cause gcrypt to step
on its own toes.

I'll fix this and see if the problem goes away.

- --
??? ?????????????? ??? http://www.cowlark.com ???????????????????
? "Parents let children ride bicycles on the street. But parents do not
? allow children to hear vulgar words. Therefore we can deduce that cursing
? is more dangerous than being hit by a car." --- Scott Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJArzf9E0noFvlzgRAp8uAJwMELeePd61OgydP9wDp5qi8bktxwCglsLH
lLz7wkVAudzDCJ3U4EV6YFY=
=+b83
-----END PGP SIGNATURE-----



From gcrypt-devel at mlists.thewrittenword.com  Fri Apr 27 22:24:35 2007
From: gcrypt-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Fri, 27 Apr 2007 15:24:35 -0500
Subject: allow setting of egd socket path
Message-ID: <20070427202435.GA6228@localhost.localdomain>

Hi,

Some systems do not have a good entropy source, so we use PRNGD to
provide it. When we build libgcrypt we use the --with-egd-socket
configure flag to tell libgcrypt where to expect to find the socket.
So all is good, as long as PRNGD is running with the socket in the
right location. If not, and the user does not have rights to start it
with the socket at that path, they can not use libgcrypt. 

We'd like the user to be able to set a different entropy source, for
example using curl's --egd-file flag, and have libgcrypt respect that.
I thought the new GCRYCTL_SET_RANDOM_DAEMON_SOCKET stuff in trunk
would be what we wanted, but it's not.

I notice in the NEWS file of the svn version "Changed the way the RNG
gets initialized." - does this mean that we will be able to run `curl
--verion' and not have it die complaining about being unable to find a
valid entropy source? I realize that this was discussed previously,
but I am not convinced that a library calling exit(2) on the
appliction is a good idea. In the case above, curl inits everything at
the beginning of its main() function, including gnutls, gnutls then
proceeds to init libgcrypt, which calls exit(2) because PRNGD is not
running. It is pretty doubtful that curl wants to encrypt its version
output though :). Is this a misuse of the API by curl/gnutls? 

Anyway, please consider the attached patch for inclusion.

Thanks,
Peter

-------------- next part --------------
Index: src/global.c
===================================================================
--- src/global.c	(revision 1234)
+++ src/global.c	(working copy)
@@ -354,6 +354,10 @@
       _gcry_use_random_daemon (!! va_arg (arg_ptr, int));
       break;
 
+    case GCRYCTL_SET_EGD_SOCKET_PATH:
+      err = _gcry_set_egd_socket_path(va_arg (arg_ptr, const char *));
+      break;
+
     default:
       err = GPG_ERR_INV_OP;
     }
Index: src/gcrypt.h.in
===================================================================
--- src/gcrypt.h.in	(revision 1234)
+++ src/gcrypt.h.in	(working copy)
@@ -355,7 +355,8 @@
     GCRYCTL_FAST_POLL = 48,
     GCRYCTL_SET_RANDOM_DAEMON_SOCKET = 49,
     GCRYCTL_USE_RANDOM_DAEMON = 50,
-    GCRYCTL_FAKED_RANDOM_P = 51
+    GCRYCTL_FAKED_RANDOM_P = 51,
+    GCRYCTL_SET_EGD_SOCKET_PATH = 52
   };
 
 /* Perform various operations defined by CMD. */
Index: cipher/rndegd.c
===================================================================
--- cipher/rndegd.c	(revision 1234)
+++ cipher/rndegd.c	(working copy)
@@ -39,7 +39,20 @@
 #endif
 
 static int egd_socket = -1;
+static char * user_egd_socket_path = NULL;
 
+int
+_gcry_set_egd_socket_path(const char * path)
+{
+  if ((NULL == user_egd_socket_path) && (egd_socket == -1))
+    {
+    user_egd_socket_path = gcry_xstrdup (path);
+    return 0;
+    }
+  return 1;
+}
+
+
 /* Allocate a new filename from FIRST_PART and SECOND_PART and to
    tilde expansion for first_part.  SECOND_PART might be NULL.
  */
@@ -141,6 +154,9 @@
   else
     name = my_make_filename (bname, NULL);
 
+  if (user_egd_socket_path)
+    name = user_egd_socket_path;
+
   if (strlen(name)+1 >= sizeof addr.sun_path)
     log_fatal ("EGD socketname is too long\n");
   
Index: cipher/random.h
===================================================================
--- cipher/random.h	(revision 1234)
+++ cipher/random.h	(working copy)
@@ -47,6 +47,8 @@
                                void *buffer, size_t length);
 #endif /*USE_RANDOM_DAEMON*/
 
+int _gcry_set_egd_socket_path(const char * path);
+
 #endif /*G10_RANDOM_H*/
 
 

From gcrypt-devel at mlists.thewrittenword.com  Fri Apr 27 22:43:02 2007
From: gcrypt-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Fri, 27 Apr 2007 15:43:02 -0500
Subject: allow setting of egd socket path
In-Reply-To: <20070427202435.GA6228@localhost.localdomain>
References: <20070427202435.GA6228@localhost.localdomain>
Message-ID: <20070427204302.GB6228@localhost.localdomain>

On Fri, Apr 27, 2007 at 03:24:35PM -0500, Peter O'Gorman wrote:
> Hi,
[snipped]

Well, it helps if the patch builds on systems that do have
/dev/random.

Attept 2 attached.

Peter
-------------- next part --------------
Index: src/global.c
===================================================================
--- src/global.c	(revision 1234)
+++ src/global.c	(working copy)
@@ -354,6 +354,14 @@
       _gcry_use_random_daemon (!! va_arg (arg_ptr, int));
       break;
 
+    case GCRYCTL_SET_EGD_SOCKET_PATH:
+#if USE_RNDEGD
+      err = _gcry_set_egd_socket_path(va_arg (arg_ptr, const char *));
+#else 
+      err = GPG_ERR_NOT_IMPLEMENTED;
+#endif
+      break;
+
     default:
       err = GPG_ERR_INV_OP;
     }
Index: src/gcrypt.h.in
===================================================================
--- src/gcrypt.h.in	(revision 1234)
+++ src/gcrypt.h.in	(working copy)
@@ -355,7 +355,8 @@
     GCRYCTL_FAST_POLL = 48,
     GCRYCTL_SET_RANDOM_DAEMON_SOCKET = 49,
     GCRYCTL_USE_RANDOM_DAEMON = 50,
-    GCRYCTL_FAKED_RANDOM_P = 51
+    GCRYCTL_FAKED_RANDOM_P = 51,
+    GCRYCTL_SET_EGD_SOCKET_PATH = 52
   };
 
 /* Perform various operations defined by CMD. */
Index: cipher/rndegd.c
===================================================================
--- cipher/rndegd.c	(revision 1234)
+++ cipher/rndegd.c	(working copy)
@@ -39,7 +39,20 @@
 #endif
 
 static int egd_socket = -1;
+static char * user_egd_socket_path = NULL;
 
+int
+_gcry_set_egd_socket_path(const char * path)
+{
+  if ((NULL == user_egd_socket_path) && (egd_socket == -1))
+    {
+    user_egd_socket_path = gcry_xstrdup (path);
+    return 0;
+    }
+  return 1;
+}
+
+
 /* Allocate a new filename from FIRST_PART and SECOND_PART and to
    tilde expansion for first_part.  SECOND_PART might be NULL.
  */
@@ -141,6 +154,9 @@
   else
     name = my_make_filename (bname, NULL);
 
+  if (user_egd_socket_path)
+    name = user_egd_socket_path;
+
   if (strlen(name)+1 >= sizeof addr.sun_path)
     log_fatal ("EGD socketname is too long\n");
   
Index: cipher/random.h
===================================================================
--- cipher/random.h	(revision 1234)
+++ cipher/random.h	(working copy)
@@ -47,6 +47,8 @@
                                void *buffer, size_t length);
 #endif /*USE_RANDOM_DAEMON*/
 
+int _gcry_set_egd_socket_path(const char * path);
+
 #endif /*G10_RANDOM_H*/
 
 

From wk at gnupg.org  Sat Apr 28 10:51:57 2007
From: wk at gnupg.org (Werner Koch)
Date: Sat, 28 Apr 2007 10:51:57 +0200
Subject: Algorithm 11 not available
In-Reply-To: <20070427161748.GB18951@jabberwocky.com> (David Shaw's message of
	"Fri\, 27 Apr 2007 12\:17\:48 -0400")
References: <87abwuayxa.fsf@newton.gmurray.org.uk> <4631F8C6.7020608@mac.com>
	<4632148E.5060006@psmay.com>
	<DB73B47AB92DEE4BAA36C6EF976AEA8F021E13CA@whexchmb05.bsna.bsroot.bear.com>
	<20070427161748.GB18951@jabberwocky.com>
Message-ID: <87ps5oev9u.fsf@wheatstone.g10code.de>

On Fri, 27 Apr 2007 18:17, dshaw at jabberwocky.com said:

> Remember that GPG2 uses libgcrypt for it's crypto, so you'll also need
> to use a libgcrypt that has SHA224.

I will release libgcrypt 1.3.0 with support for SHA224 next week.

I am not sure whether it is justified to add support for SHA224 to the
stable version of libgcrypt (1.2.4).  That depends a bit on the
development process of 1.3.x - there are some things which I would like
to see for a final 1.4 but I don't know how long that will take.  Only
in case it turns out that things will take too long it is likely that we
will backport some features.  

Although 1.3.0 will be earmarked as development it may be used in the
real world.  It might not be a good idea to use it for widely deployed
distributions.


Salam-Shalom,

   Werner




From twoaday at gmx.net  Sun Apr 29 17:10:07 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 29 Apr 2007 17:10:07 +0200
Subject: [W32] Regarding slow startup under Windows
Message-ID: <4634B54F.3040404@gmx.net>


Hi,

some time ago there was a thread about the startup time
of the random code which is implemented in Libgcrypt.

There might be an easy solution to speed up the process,
at least when the user does not want to gather random
entropy first. Threads and a simple mutex would do the job.

For example we could start the 'toolhelp32' snapshot or the
'query-perf-counter' function as a thread and maybe also other slow
gathering routines. Each function would lock a mutex at the begin and
unlocks it when the process is done.

If gcry_random_bytes() or another random function is called, it
first checks if the 'gather mutex' is unlocked, otherwise it will
wait until it is unlocked. With threads, there would be no delay at
the startup and the user can continue to use the public-key, mpi, sexp
and raw encryption API without waiting for the gathers.

Probably some other 'pool init' functions needs to be delayed also.


	Timo



From wk at gnupg.org  Mon Apr 30 16:54:16 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Apr 2007 16:54:16 +0200
Subject: allow setting of egd socket path
In-Reply-To: <20070427202435.GA6228@localhost.localdomain> (Peter O'Gorman's
	message of "Fri\, 27 Apr 2007 15\:24\:35 -0500")
References: <20070427202435.GA6228@localhost.localdomain>
Message-ID: <873b2hgbfr.fsf@wheatstone.g10code.de>

On Fri, 27 Apr 2007 22:24, gcrypt-devel at mlists.thewrittenword.com said:

> We'd like the user to be able to set a different entropy source, for
> example using curl's --egd-file flag, and have libgcrypt respect that.
> I thought the new GCRYCTL_SET_RANDOM_DAEMON_SOCKET stuff in trunk
> would be what we wanted, but it's not.

That is experimental stuff not related to egd.

I have just ciommitted your suggested change to the SVN trunk.  It is a
little bit different than your patch, though:

  @item GCRYCTL_SET_RNDEGD_SOCKET; Arguments: const char *filename
  
  This command may be used to override the default name of the EGD socket
  to connect to.  It may be used only during initialization as it is not
  thread safe.  Changing the socket name again is not supported.  The
  function may return an error if the given filename is too long for a
  local socket name.
  
  EGD is an alternative random gatherer, used only on a few systems.
  
> I notice in the NEWS file of the svn version "Changed the way the RNG
> gets initialized." - does this mean that we will be able to run `curl
> --verion' and not have it die complaining about being unable to find a
> valid entropy source? I realize that this was discussed previously,

Yes.  This is a slow initialization which does only setup the mutex
stuff on init and does the rest of the initialization on demand.

> but I am not convinced that a library calling exit(2) on the
> appliction is a good idea. In the case above, curl inits everything at

We can't change that anymore and actually your patch although did this
too by using an xmalloc.



Salam-Shalom,

   Werner