Copilot commented on code in PR #24374: URL: https://github.com/apache/camel/pull/24374#discussion_r3521844173
########## design/security.adoc: ########## @@ -237,6 +237,51 @@ Key files in the implementation: - `tooling/maven/camel-package-maven-plugin/.../UpdateSensitizeHelper.java` — code generation from component JSONs +== Shared SecureRandom + +=== Rationale + +`java.security.SecureRandom` is thread-safe but heavyweight to instantiate: each `new SecureRandom()` +call gathers OS entropy (reads from `/dev/urandom` on Linux, `CryptGenRandom` on Windows). Creating +a fresh instance per call is wasteful and measurably slows down startup when many components +initialize cryptographic material (e.g., `camel-pqc` had ~40 separate allocations). + +Since Java 9, the default `SecureRandom` implementation uses DRBG (Deterministic Random Bit +Generator) which handles concurrent access efficiently. A single shared instance is both safe and +performant. Review Comment: The doc states that since Java 9 the default `SecureRandom` uses DRBG. DRBG exists since Java 9, but whether it is the default depends on the active provider and security configuration. Suggest wording that doesn’t assert DRBG is always the default. ########## core/camel-util/src/main/java/org/apache/camel/util/SecureRandomHelper.java: ########## @@ -0,0 +1,47 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.camel.util; + +import java.security.SecureRandom; + +/** + * Provides a shared {@link SecureRandom} instance for use across Camel. + * <p> + * {@code SecureRandom} is thread-safe but heavyweight to instantiate — each {@code new SecureRandom()} call gathers OS + * entropy. Reusing a single instance avoids repeated initialization overhead while maintaining cryptographic security + * guarantees. Review Comment: The Javadoc states that each `new SecureRandom()` call gathers OS entropy, which is not guaranteed across JDKs/providers and can be misleading. Consider rephrasing to a weaker/accurate statement about provider initialization and seeding possibly being expensive. ########## design/security.adoc: ########## @@ -237,6 +237,51 @@ Key files in the implementation: - `tooling/maven/camel-package-maven-plugin/.../UpdateSensitizeHelper.java` — code generation from component JSONs +== Shared SecureRandom + +=== Rationale + +`java.security.SecureRandom` is thread-safe but heavyweight to instantiate: each `new SecureRandom()` +call gathers OS entropy (reads from `/dev/urandom` on Linux, `CryptGenRandom` on Windows). Creating +a fresh instance per call is wasteful and measurably slows down startup when many components +initialize cryptographic material (e.g., `camel-pqc` had ~40 separate allocations). + Review Comment: This rationale claims every `new SecureRandom()` call gathers OS entropy and references specific OS APIs (`/dev/urandom`, `CryptGenRandom`). That behavior is provider/JDK-dependent and the API name is outdated on modern Windows; better to avoid hard-coding these details in design docs. ########## design/security.adoc: ########## @@ -237,6 +237,51 @@ Key files in the implementation: - `tooling/maven/camel-package-maven-plugin/.../UpdateSensitizeHelper.java` — code generation from component JSONs +== Shared SecureRandom + +=== Rationale + +`java.security.SecureRandom` is thread-safe but heavyweight to instantiate: each `new SecureRandom()` +call gathers OS entropy (reads from `/dev/urandom` on Linux, `CryptGenRandom` on Windows). Creating +a fresh instance per call is wasteful and measurably slows down startup when many components +initialize cryptographic material (e.g., `camel-pqc` had ~40 separate allocations). + +Since Java 9, the default `SecureRandom` implementation uses DRBG (Deterministic Random Bit +Generator) which handles concurrent access efficiently. A single shared instance is both safe and +performant. + +=== Usage + +`SecureRandomHelper` in `camel-util` provides a shared instance via a static getter: + +[source,java] +---- +import org.apache.camel.util.SecureRandomHelper; Review Comment: PR description test plan states that no `new SecureRandom()` remains outside `SecureRandomHelper`, but there are still `new SecureRandom()` occurrences under `components/camel-pqc` (e.g., docs and tests). Either update those call sites as well, or clarify the scope (e.g., “production code only”). -- 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]
