You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Andrea Cosentino (Jira)" <ji...@apache.org> on 2026/10/07 11:38:00 UTC

[jira] [Resolved] (CAMEL-25409) camel-mongodb, camel-aws2-transcribe, camel-twitter - security metadata of three options does not match the code

     [ https://issues.apache.org/jira/browse/CAMEL-25409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrea Cosentino resolved CAMEL-25409.
--------------------------------------
    Resolution: Fixed

> camel-mongodb, camel-aws2-transcribe, camel-twitter - security metadata of three options does not match the code
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25409
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25409
>             Project: Camel
>          Issue Type: Bug
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.23.0
>
>
> A sweep of every option in the generated catalog against the security metadata the policy framework relies on (SecurityUtils, see design/security.adoc) turned up three options whose metadata does not match what the code does. All three are metadata-only defects - no runtime behaviour changes, and in every case the runtime default is the safe one - but each defeats a mechanism that is supposed to catch misconfiguration.
> *1. camel-mongodb: tlsAllowInvalidHostnames is 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 sslEndpointAlgorithm via CAMEL-24056, the AWS trustAllCertificates family, netty hostnameVerification, splunk-hec skipTlsVerify). Because the security option map is keyed by the bare option name, nothing named tlsAllowInvalidHostnames is known to it, so camel.main.profile=prod does not refuse it.
> *2. camel-aws2-transcribe: trustAllCertificates advertises defaultValue=true*
> Transcribe2Configuration declares @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 say the default is true. Every other AWS component declares defaultValue = "false". The option itself is live (consumed by AwsClientBuilderUtil), so this is purely wrong advertised metadata - but it tells users that an AWS component ships trusting all certificates.
> *3. camel-twitter: component-level httpProxyPassword is not marked as a secret*
> AbstractTwitterComponent#httpProxyPassword has @Metadata(label = "proxy") with no security = "secret", while the endpoint-level twin in TwitterConfiguration has it. The catalog therefore reports secret=true for the endpoint option and secret=false for the component property of the same name, for twitter-directmessage, twitter-search and twitter-timeline. Sanitized URIs still mask it through SensitiveUtils, but the plain-text-secret check and UI masking skip the component-level property.
> *Follow-up, not included here*
> camel-debezium-mongodb has the same gap as (1) on mongodbSslInvalidHostnameAllowed, but that configuration class is generated by camel-debezium-maven-plugin, so fixing it means teaching ConnectorConfigGenerator about security-sensitive option names and regenerating every connector. That is worth a separate issue rather than being folded in here.
> _Reported by Claude Code on behalf of @oscerd_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)