nishat-06 opened a new pull request, #8613:
URL: https://github.com/apache/hadoop/pull/8613

   ### Description of PR
   
   `hadoop.security.sensitive-config-keys` lists credential keys for the s3a, 
azure, adl and gs connectors only, so the obs, oss, cosn, tos and bos 
connectors have their secret keys and session tokens matched by no pattern. 
`ConfigRedactor.configIsSensitive` returns false for all of them, and 
`Configuration.dumpConfiguration` / `writeXml` then emit the values verbatim, 
so the `/conf` servlet on the NameNode, DataNode, ResourceManager, NodeManager 
and HttpFS hands out object store secrets and session tokens in cleartext, as 
does reconfiguration logging through `ReconfigurableBase`.
   
   The thirteen missing patterns are added to both `core-default.xml` and 
`CommonConfigurationKeysPublic.HADOOP_SECURITY_SENSITIVE_CONFIG_KEYS_DEFAULT`, 
since the latter is what applies when `core-default.xml` is off the classpath. 
Bucket-scoped forms follow the existing `fs.s3a.secret.key` / 
`fs.s3a.*.secret.key` shape. Access key ids are deliberately left unredacted, 
matching how `fs.s3a.access.key` is treated today.
   
   ### How was this patch tested?
   
   `TestConfigRedactor` covers this through its existing 
`testRedactWithCoreDefault` and `testRedactNoCoreDefault` pair, so the added 
keys are asserted against both the XML default and the Java constant. Each of 
the thirteen keys is redacted with the patch and returned in cleartext without 
it.
   
   Local surefire did not run to completion on my machine (the build host ran 
out of disk), so I verified by driving `ConfigRedactor` directly against the 
built `hadoop-common` jar over both config paths, and separately replayed the 
pre-patch pattern list from trunk to confirm the same thirteen keys come back 
unredacted. I also matched the new patterns against every `<name>` in the 
tree's `*-default.xml` files to check for over-matching, which returned no 
hits. Full CI results here would be welcome.
   
   ### For code changes:
   
   - [ ] Does the title or this PR starts with the corresponding JIRA issue id 
(e.g. 'HADOOP-17799. Your PR title ...')?
   - [ ] Object storage: have the integration tests been executed and the 
endpoint declared according to the connector-specific documentation?
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`, 
`NOTICE-binary` files?
   
   No JIRA id yet and no new dependencies; no connector code is touched, so the 
object store integration suites do not apply. Happy to open a JIRA and retitle 
if that is preferred before review.
   
   ### AI Tooling
   
   If an AI tool was used:
   
   - [x] The PR includes the phrase "Contains content generated by <tool>"
         where <tool> is the name of the AI tool used.
   - [x] My use of AI contributions follows the ASF legal policy
         https://www.apache.org/legal/generative-tooling.html
   
   Contains content generated by BugQore, a multi-agent AI code review system. 
The finding, the patch and this description were produced with it and reviewed 
by me before submitting.
   


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


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to