Mailing List Archive

Nikos Mavrogiannopoulos wrote:
> On Saturday 10 September 2005 10:34, Nikos Mavrogiannopoulos wrote:

> > The problem is that in the 2nd forked session the server tries to resume
> > the previous connection. You can check this by looking the session ID. The
> > one the server selects the second time is the same as the client requested
> > (resume). This is totally strange since there is no communication
> > between the objects (lie in a different process), so the second process
> > shoudn't even know the session ID of the first server process.
> > It seems to work ok if you move the gnutls_session_t session declaration to
> > after the forked process has been created (after if (pid==0)). I'm still
> > looking at it but it really looks odd.

> The problem seems to be libgcrypt's random generator. As far as I understand
> when you fork() the random generator is on the same state for every children.
> That's why the server produces the same session ID in the second process.

Either fork() much earlier or use exec*() after fork() to get a process
in a clean state.

--
Christian

On Sat, 10 Sep 2005 11:12:42 +0200, Nikos Mavrogiannopoulos said:

> The problem seems to be libgcrypt's random generator. As far as I understand
> when you fork() the random generator is on the same state for every children.

I just checked it and indeed the fork detection code used to help only
against other threads forking but not againts plain forks without
execs. I have changed this and added fork detection to
gcry_create_nonce too. Added regression tests for these two cases.

Please checkout

svn://cvs.gnupg.org/libgcrypt/branches/LIBGCRYPT-1-2-BRANCH

this should fix the problem. If it is okay for you; I can do a new
release today.


Salam-Shalom,

Werner