Update RUSTSEC-0000-0000.md

Author: mmastrac

crates/openssl-probe/RUSTSEC-0000-0000.md

@@ -22,25 +22,28 @@ patched = [">= 0.1.6"]
 
 # `openssl-probe` may cause memory corruption in multi-threaded processes
 
-`openssl-probe` offers non-`unsafe` methods that call environment setters, which may be called
+`openssl-probe` offers non-`unsafe` methods that call `std::env::set_var`, which may be called
 in a multithreaded environment, and potentially clash with environment access on other threads.
 
 When these methods are called while other threads are active and accessing the environment, it
-may cause the other threads to access dangling pointer values in the cases where the underlying
+may cause other threads to access dangling environment pointers in the cases where the underlying
 environment data is moved or resized in response to an additional environment variable being
 added, or a variable's contents being enlarged.
 
 This is shown to occur on Linux, but it will also likely occur on any other platform where `getenv`
 and `setenv` are not thread-safe, though trigger conditions may vary widely.
 
+Note that these function calls are completely safe and sound in purely single-threaded environments,
+or multi-threaded environments where it can be proven that no simultaneous read and writes to the
+environment occur.
+
 ## Rust's `set_env`
 
-This crate, and all callers of the Rust `set_env` function (<https://doc.rust-lang.org/std/env/fn.set_var.html>)
-are unsound due to some early decisions in the Rust ecosystem that provided these functions without
-an `unsafe` marker. The real problem, however, lies in the POSIX standard which defines this method
+This crate, and all other callers of the Rust `set_env` function (<https://doc.rust-lang.org/std/env/fn.set_var.html>)
+are unsound due to the unfortunate reality of the POSIX standard which defines these enviornment access methods
 without making any sort of thread-safety guarantees.
 
-In Rust's 2024 edition these environment setters are made `unsafe` and the documentation was updated to note
+In Rust's 2024 edition `std::env::set_var` is marked as `unsafe` and the documentation was updated to note
 that the only safe way to use these functions is in a single-threaded context.
 
 ## Affected Code
@@ -52,11 +55,11 @@ any other library's function which may call this function directly or indirectly
 do so in certain configurations <https://github.com/sfackler/rust-native-tls/blob/2424bc5efd1b8b4bcf60dbda93259a3f29db7f06/Cargo.toml>.
 
 The crate's author released a fix in versions `>=0.1.6` which marks these functions as `#[deprecated]` and adds
-new `unsafe` equivalents <https://github.com/alexcrichton/openssl-probe/commit/3ea7c1af24d7f03c5786872f06ff066e03b75138>.
+new `unsafe` equivalents with safety guidance <https://github.com/alexcrichton/openssl-probe/commit/3ea7c1af24d7f03c5786872f06ff066e03b75138>.
 
 ## Alternative Mitigations
 
-In the case of glibc users, some thread-safety improvements may protect you from `setenv`/`getenv` clashes
+In the case of glibc users, some future thread-safety improvements may protect you from `setenv`/`getenv` clashes
 which were introduced in <https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6fca5e2d1f13f65685c61>,
 however direct `environ` access in multithreaded programs will still risk dangling pointer access.