SEZ9 opened a new issue, #12069: URL: https://github.com/apache/seatunnel/issues/12069
### Search before asking - [X] I had searched in the [feature](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22Feature%22) and found no similar feature requirement. ### Description `base64` is the built-in `ConfigShade` implementation, and it is the one most users reach for first because it works with no setup: ```conf env { shade.identifier = "base64" } sink { Jdbc { user = "c2VhdHVubmVs" password = "c2VhdHVubmVs" } } ``` The name gives no hint that the result is reversible by anyone who can read the config file - `echo c2VhdHVubmVs | base64 -d` is the whole attack. The docs do say it is "not recommended for production use", but nothing says so at the point where it is actually used, and a config that has been through `POST /encrypt-config` *looks* protected. The result is configs checked into Git, pasted into tickets, and shipped in Docker images under the belief that the credentials in them are encrypted. ### Usage Scenario Anyone who enabled `shade.identifier = "base64"` to keep plaintext credentials out of a config file, without reading the paragraph in the docs that says it does not do that. Proposal: log a warning from `ConfigShadeUtils` when a config is decrypted with the `base64` shade, so an operator who picked it by accident finds out from the job log instead of from an incident. Behaviour is unchanged; this is one log line. ### Related issues _No response_ ### Are you willing to submit a PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
