oscerd opened a new pull request, #27482: URL: https://github.com/apache/camel/pull/27482
Three options whose security metadata does not match what the code does, found by sweeping every option in the generated catalog against the metadata the security policy framework relies on (`SecurityUtils`, see [`design/security.adoc`](https://github.com/apache/camel/blob/main/design/security.adoc)). All three are metadata-only defects — **no runtime behaviour changes, and the runtime default is the safe one in every case** — but each one defeats a mechanism that exists to catch misconfiguration. ### 1. camel-mongodb: `tlsAllowInvalidHostnames` was not marked `insecure:ssl` `MongoDbEndpoint#tlsAllowInvalidHostnames` is declared as a plain `@UriParam(label = "security")`, but setting it calls `builder.invalidHostNameAllowed(true)` — it disables TLS hostname verification exactly like the options that *do* carry `security = "insecure:ssl"` (camel-kafka's `sslEndpointAlgorithm` via CAMEL-24056, the AWS `trustAllCertificates` family, netty `hostnameVerification`, splunk-hec `skipTlsVerify`). The security option map is keyed by the bare option name, so nothing named `tlsAllowInvalidHostnames` was known to it and `camel.main.profile=prod` did not refuse it. ### 2. camel-aws2-transcribe: `trustAllCertificates` advertised `defaultValue = "true"` `Transcribe2Configuration` declared `@UriParam(security = "insecure:ssl", defaultValue = "true")` on a bare `boolean` field — so the runtime default is `false`, while the catalog, the component documentation and the generated DSL builders all said the default is `true`. Every other AWS component declares `"false"`. The option is live (consumed by `AwsClientBuilderUtil`), so nothing was actually insecure; the metadata simply told users that an AWS component ships trusting all certificates. ### 3. camel-twitter: component-level `httpProxyPassword` was not marked secret `AbstractTwitterComponent#httpProxyPassword` had `@Metadata(label = "proxy")` with no `security = "secret"`, while the endpoint-level twin in `TwitterConfiguration` has it — so the catalog reported `secret=true` for the endpoint option and `secret=false` for the component property of the same name, across twitter-directmessage, twitter-search and twitter-timeline. Sanitized URIs still masked it through `SensitiveUtils`, but the plain-text-secret check and UI masking skipped the component property. ### Tests `SecurityUtilsTest` gains a case asserting that the hostname-verification options reach the policy map, so a future option of this kind cannot silently go unregistered. ### Not included `camel-debezium-mongodb` has the same gap as (1) on `mongodbSslInvalidHostnameAllowed`, but that configuration class is generated by `camel-debezium-maven-plugin`; fixing it means teaching `ConnectorConfigGenerator` about security-sensitive option names and regenerating every connector. Noted on the JIRA as a separate follow-up rather than folded in here. JIRA: https://issues.apache.org/jira/browse/CAMEL-25409 _Claude Code on behalf of @oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
