pjfanning opened a new pull request, #3481: URL: https://github.com/apache/pekko/pull/3481
### Motivation The TLS docs told users that on Linux with `SHA1PRNG` they should set `-Djava.security.egd=file:/dev/urandom` *"to prevent blocking"*, and that doing so *"is NOT as secure because it reuses the seed"*. Both halves are wrong on any JDK Pekko supports. **"It reuses the seed"** — nothing about `/dev/urandom` reuses a seed. Since Linux 4.8 both devices draw from the same CSPRNG. The note's instinct is sound but attached to the wrong cause: the real caveat belongs to the *algorithm*. In `sun.security.provider.SecureRandom`, `SHA1PRNG` seeds `state` once when it is null and then runs a deterministic SHA-1 chain forever, whereas the platform default `NativePRNG` mixes fresh kernel randomness into every `nextBytes` call. That holds whatever `java.security.egd` is set to, so the flag is irrelevant to the concern being raised. **"To prevent blocking"** — close to inert. In `SeedGenerator`, `file:/dev/urandom` selects `NativeSeedGenerator`, which on Unix is just `URLSeedGenerator` reading that path; the special case only means something on Windows. The default `securerandom.source` is `file:/dev/random`, which since kernel 5.6 no longer blocks once the pool is seeded at boot. The advice mattered on old kernels in low-entropy VMs. The same stale rationale is repeated in the `reference.conf` comments, which justify avoiding `SHA1PRNG` on the grounds of *"blocking issues on Linux"*. ### Modification Rewrite the note in `remote-security.md` (artery) and `remoting.md` (classic) to: - lead with the recommendation to keep the platform default `SecureRandom`; - give the no-reseeding property as the reason to prefer it over `SHA1PRNG`; - describe the entropy source accurately, with the blocking concern marked as historical. Also fixes the missing "to" in the classic copy (*"it's recommended specify"*), and updates the three `reference.conf` comments to match. ### Result The note states a caveat that is true and actionable, and no longer advises a JVM flag on grounds that have not applied for several kernel releases. `reference.conf` changes are comment-only — no defaults, behaviour, or public API are affected. ### Tests - Not run - docs only ### References None - follow-up from the threat model review in #3478 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
