oscerd commented on PR #27117:
URL: https://github.com/apache/camel/pull/27117#issuecomment-5948078335

   Thanks, all four points are addressed in `720dc51972ce`.
   
   **1. Runtime side effect.** Restricted to the owner, as you suggested. 
`SecurityUtils.getSecurityOption` no longer lets a configuration key without a 
component, data format or language owner match an option that only languages 
declare. `camel.language.simple.nested`, `camel.language.file.nested` and the 
scanner's bare `nested` still match; `camel.beans.foo.nested`, `camel.main.*` 
and `camel.kamelet.*` keys ending in `nested` no longer do.
   
   Component and data format options keep matching such keys by name on 
purpose, because `camel.beans.*` can configure a component or data format bean 
(for example `camel.beans.myClient.trustAllCertificates`). `nested` is the only 
option that only languages declare today, so nothing else changes.
   
   With that restriction there is no upgrade-guide entry: `nested` is an 
attribute of the expression rather than a property of the language, so 
camel-main has no real configuration key that would now be flagged.
   
   **2. Scanner test.** Added `detectsNestedSimpleExpression`. `nested: true` 
on a simple expression is reported as `insecure:dev`; `nested: false`, 
`isNested` and `unnested: true` are not.
   
   **3. Category.** Kept `insecure:dev` on purpose. It is the category of the 
other injection-shaped opt-ins (`allowTemplateFromHeader`, 
`allowPredicateFromMessage`, `allowQueryFromHeader`), and the categories are a 
closed set with one policy option each, so a new category would also need its 
own policy option.
   
   **4. Name-only scanner matches.** Agreed: a constant body such as 
`{"nested":true}` is still reported. The scanner is advisory and line-based, so 
it cannot tell an expression attribute from data. The token-boundary check at 
least removes the `isNested` / `unnested` cases.
   
   _Claude Code on behalf of oscerd_
   


-- 
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]

Reply via email to