Message 195788 - Python tracker

Message195788

Author	pitrou
Recipients	barry, benjamin.peterson, christian.heimes, georg.brandl, neologix, pitrou, python-dev, sbt, vstinner
Date	2013-08-21.13:23:42
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<244612104.2745072.1377091416489.JavaMail.root@zimbra10-e2.priv.proxad.net>
In-reply-to	<1377090535.96.0.400666901962.issue18747@psf.upfronthosting.co.za>

Content
> Do you have a proposal for a better way to fix the issue? I don't > think that we can hope for a fix from OpenSSL. Instead of reseeding in the child, you can perturb the state in the parent after fork. As far as I understand, only the "child" callback in pthread_atfork() needs to be async-signal-safe: "It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available." http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html

Content

> Do you have a proposal for a better way to fix the issue? I don't
> think that we can hope for a fix from OpenSSL.

Instead of reseeding in the child, you can perturb the state in the parent
after fork. As far as I understand, only the "child" callback in
pthread_atfork() needs to be async-signal-safe:

"It is suggested that programs that use fork() call an exec function
very soon afterwards in the child process, thus resetting all states.
In the meantime, only a short list of async-signal-safe library
routines are promised to be available."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html

History
Date	User	Action	Args
2013-08-21 13:23:43	pitrou	set	recipients: + pitrou, barry, georg.brandl, vstinner, christian.heimes, benjamin.peterson, neologix, python-dev, sbt
2013-08-21 13:23:43	pitrou	link	issue18747 messages
2013-08-21 13:23:42	pitrou	create