Commit dcb9027164 for openssl.org

commit dcb9027164bb8f7e50fc5067664419f75ffaec10
Author: Yuxiang Ji <kurath0307@icloud.com>
Date:   Tue Nov 3 19:11:09 2026 +0800

    doc: RAND(7): a fork that keeps the PID continues the generator

    The DRBGs tell a child from its parent by the process ID.  After
    a process with process ID 1 calls unshare(2) with CLONE_NEWPID,
    the child it creates by fork(2) is process 1 of the new PID namespace,
    so the check sees no change and the child continues its parent's
    generator.  Say so beside the statement on fork(2), and tell
    applications that create such a child to reseed in it,
    with RAND_poll(3) as the call that does it.

    Assisted-by: Claude Code:claude-opus-5-5
    Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
    Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
    Reviewed-by: Jakub Zelenka <jakub.zelenka@openssl.foundation>
    Merge-date: Wed Nov 11 09:07:14 2026
    Merged-from: https://github.com/openssl/openssl/pull/33508

diff --git a/doc/man7/RAND.pod b/doc/man7/RAND.pod
index 8b837651ac..9f8db0dc34 100644
--- a/doc/man7/RAND.pod
+++ b/doc/man7/RAND.pod
@@ -38,15 +38,19 @@ For more details on reseeding and error recovery, see L<EVP_RAND(7)>.
 The automatic reseeding reacts to a change of the process ID (a child created
 by fork(2) does not continue its parent's generator), to the number of
 requests made and to the time elapsed since the last reseed; see L<EVP_RAND(7)>.
-It does not detect that the process, or the virtual machine it runs in, has
-been restored from a saved image: a virtual machine restored from a snapshot,
-a process restored from a checkpoint, or a function resumed from an image
-continues from the generator state in the image, and several copies restored
-from one image produce the same output until their next scheduled reseed.
-An application that runs where such a restore can happen should reseed after
-its own restore signal, for example by calling L<RAND_poll(3)>, which reseeds
-the primary DRBG; the public and private DRBGs then reseed from it at their
-next request.
+A child that keeps its parent's process ID does continue it: after a process
+with process ID 1 calls unshare(2) with B<CLONE_NEWPID>, the child it creates
+by fork(2) is process 1 of the new PID namespace.
+The automatic reseeding also does not detect that the process, or the virtual
+machine it runs in, has been restored from a saved image: a virtual machine
+restored from a snapshot, a process restored from a checkpoint, or a function
+resumed from an image continues from the generator state in the image, and
+several copies restored from one image produce the same output until their
+next scheduled reseed.
+An application that creates such a child, or that runs where such a restore
+can happen, should reseed in the child or after its own restore signal, for
+example by calling L<RAND_poll(3)>, which reseeds the primary DRBG; the public
+and private DRBGs then reseed from it at their next request.

 For values that should remain secret, you can use L<RAND_priv_bytes(3)>
 instead.