gnutls 1.2.6 and Mozilla Firefox compatibility problem
christianbiere at gmx.de
Sat Sep 10 17:39:57 CEST 2005
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available
Url : /pipermail/attachments/20050910/1c787d6d/attachment.pgp
More information about the Gcrypt-devel