Commit d60fad179e for openssl.org

commit d60fad179ebe896a6b1c65e1c857556e145994c3
Author: kovan <xaum.io@gmail.com>
Date:   Thu Jan 29 15:13:28 2026 +0100

    doc: add SSL/SSL_CTX thread safety section to openssl-threads

    Add explicit documentation about thread safety of SSL and SSL_CTX
    objects, clarifying that:
    - SSL_CTX can be shared among threads but should be treated as
      read-only after creating SSL objects or sharing across threads
    - SSL connection objects should only be used by one thread at a time
    - Each thread handling TLS connections should create its own SSL object

    Fixes #23446

    Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
    (cherry picked from commit 13bce9ed63db177a37bfd6ec22d9378b27f6f9cc)

    Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
    Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
    Reviewed-by: Milan Broz <mbroz@openssl.org>
    Reviewed-by: Bob Beck <beck@openssl.org>
    MergeDate: Tue May 26 13:19:35 2026
    (Merged from https://github.com/openssl/openssl/pull/29847)

diff --git a/doc/man7/openssl-threads.pod b/doc/man7/openssl-threads.pod
index 7f29a327ac..bf2b2fb553 100644
--- a/doc/man7/openssl-threads.pod
+++ b/doc/man7/openssl-threads.pod
@@ -84,6 +84,14 @@ In this specific case, and probably for factory methods in general, it is
 not safe to modify the factory object after it has been used to create
 other objects.

+An B<SSL> connection object created by L<SSL_new(3)> should only be used
+by a single thread at a time.
+While it is possible for one thread to use an B<SSL> object and then pass
+it to another thread, the application must ensure that no two threads
+are using the same B<SSL> object concurrently.
+Each thread handling TLS connections in parallel should create its own
+B<SSL> object from the shared B<SSL_CTX>.
+
 =head1 SEE ALSO

 CRYPTO_THREAD_run_once(3),