gnodet-bot commented on code in PR #27409:
URL: https://github.com/apache/camel/pull/27409#discussion_r4206459438
##########
docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc:
##########
@@ -3700,6 +3700,44 @@ When `camel.opentelemetry.*` properties are configured
but OpenTelemetry is disa
the `camel.opentelemetry2.*` or `camel.telemetryDev.*` properties are now
used. Previously they were ignored whenever
any `camel.opentelemetry.*` property was configured.
+=== camel-main - `CAMEL_COMPONENT_*`, `CAMEL_DATAFORMAT_*`, `CAMEL_LANGUAGE_*`
environment variables now take effect
+
+Two bugs in `camel-main`'s environment-variable processing were fixed and are
now active.
+
+**Bug 1 — variables were silently ignored since Camel 3.9 (CAMEL-16345)**
+
+`filterEnvVariables` uppercases the variable names before comparing them
against the supplied prefixes, so the prefixes
+themselves must be uppercase. Before this fix the code passed lowercase
prefixes (`camel.component.`, etc.), causing
+every match to fail silently. This has been corrected: `CAMEL_COMPONENT_*`,
`CAMEL_DATAFORMAT_*` and `CAMEL_LANGUAGE_*`
+variables are now actually read.
+
+If your deployments intentionally set such variables but relied on them being
ignored (for example to pass secrets that
+should not reach the component), use
+`camel.main.autoConfigurationEnvironmentVariablesEnabled=false` to opt out, or
remove the variables.
+
+Variables that refer to a name not present on the classpath (for example
`CAMEL_COMPONENT_KAFKA_BROKERS` in an
+application that does not include camel-kafka) will fail the startup with an
`IllegalArgumentException`. There is no
+per-variable opt-out: rename the variable, remove it, or set
+`camel.main.autoConfigurationEnvironmentVariablesEnabled=false`.
+
+Secrets passed as component environment variables (for example
`CAMEL_COMPONENT_AWS2_S3_SECRET_KEY`) will be seen by
+the `prod`-profile security check as plain-text secrets and will fail the
startup. Use a property-placeholder instead:
+`camel.component.aws2-s3.secret-key={{env:CAMEL_COMPONENT_AWS2_S3_SECRET_KEY}}`
or configure the value through a
+vault.
+
+**Bug 2 — ambiguous name resolution**
+
+When the catalog contained component/dataformat/language pairs whose names
were prefixes of each other (such as `netty`
+/ `netty-http`, `js` / `jsonpath`, `avro` / `avroJackson`), the variable was
randomly mapped to either name.
+A longest-match strategy now always selects the most specific name.
+
+**Known limitation — `rest` / `rest-api`**
+
+`CAMEL_COMPONENT_REST_API_DOC=api.json` is matched to
`camel.component.rest-api.doc` (the longer match), not to
+`camel.component.rest.apiDoc`. Use `CAMEL_COMPONENT_REST_APIDOC=api.json`
instead (option names are matched
+case-insensitively), or configure the option directly:
+`camel.component.rest.apiDoc={{env:CAMEL_COMPONENT_REST_API_DOC}}`.
+
Review Comment:
⚠️ **Same self-defeating pattern**: `CAMEL_COMPONENT_REST_API_DOC` will be
matched by `filterEnvVariables` via the longestMatch logic to `rest-api` +
option `doc` (introduced in this PR), and bound literally to
`camel.component.rest-api.doc`. The `{{env:CAMEL_COMPONENT_REST_API_DOC}}`
placeholder in `camel.component.rest.apiDoc` runs *in addition to* (not instead
of) that auto-binding — the env var is not suppressed.
The `CAMEL_COMPONENT_REST_APIDOC=api.json` alternative mentioned above is
actually sound for reaching `rest.apiDoc`, but the `{{env:...}}` form at the
end should be removed or corrected.
##########
docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc:
##########
@@ -3700,6 +3700,44 @@ When `camel.opentelemetry.*` properties are configured
but OpenTelemetry is disa
the `camel.opentelemetry2.*` or `camel.telemetryDev.*` properties are now
used. Previously they were ignored whenever
any `camel.opentelemetry.*` property was configured.
+=== camel-main - `CAMEL_COMPONENT_*`, `CAMEL_DATAFORMAT_*`, `CAMEL_LANGUAGE_*`
environment variables now take effect
+
+Two bugs in `camel-main`'s environment-variable processing were fixed and are
now active.
+
+**Bug 1 — variables were silently ignored since Camel 3.9 (CAMEL-16345)**
+
+`filterEnvVariables` uppercases the variable names before comparing them
against the supplied prefixes, so the prefixes
+themselves must be uppercase. Before this fix the code passed lowercase
prefixes (`camel.component.`, etc.), causing
+every match to fail silently. This has been corrected: `CAMEL_COMPONENT_*`,
`CAMEL_DATAFORMAT_*` and `CAMEL_LANGUAGE_*`
+variables are now actually read.
+
+If your deployments intentionally set such variables but relied on them being
ignored (for example to pass secrets that
+should not reach the component), use
+`camel.main.autoConfigurationEnvironmentVariablesEnabled=false` to opt out, or
remove the variables.
+
+Variables that refer to a name not present on the classpath (for example
`CAMEL_COMPONENT_KAFKA_BROKERS` in an
+application that does not include camel-kafka) will fail the startup with an
`IllegalArgumentException`. There is no
+per-variable opt-out: rename the variable, remove it, or set
+`camel.main.autoConfigurationEnvironmentVariablesEnabled=false`.
+
+Secrets passed as component environment variables (for example
`CAMEL_COMPONENT_AWS2_S3_SECRET_KEY`) will be seen by
+the `prod`-profile security check as plain-text secrets and will fail the
startup. Use a property-placeholder instead:
+`camel.component.aws2-s3.secret-key={{env:CAMEL_COMPONENT_AWS2_S3_SECRET_KEY}}`
or configure the value through a
+vault.
+
Review Comment:
⚠️ **Self-defeating workaround**: `filterEnvVariables` (now using
`CAMEL_COMPONENT_` prefix correctly after this fix) will also match
`CAMEL_COMPONENT_AWS2_S3_SECRET_KEY` and bind its literal value directly. The
`{{env:...}}` placeholder doesn't suppress the direct auto-binding — it only
adds a *second* binding. The security concern this is trying to address is not
resolved by this suggestion.
Safer alternatives to document:
- `camel.main.autoConfigurationEnvironmentVariablesEnabled=false` + vault
- Rename the env var to avoid the `CAMEL_COMPONENT_` prefix entirely
--
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]
