SEZ9 commented on issue #12407: URL: https://github.com/apache/seatunnel/issues/12407#issuecomment-6246034419
Hi @JAEKWANG97, thanks for volunteering — the initial design work is still available and you are welcome to take it. There is no open KeyProvider implementation PR, so nobody else is on this scope. As noted above, the first deliverable should stay a design/STIP discussion rather than a provider implementation: `FieldEncrypt` still requires a direct `key`, the `Encryptor` SPI only exposes `init(String key)` plus encrypt/decrypt, and the encryptor is discovered lazily from the transform path, so the compatible provider/cipher boundary needs to be defined before any code lands. Your outline already lines up with the points listed in the previous comment: compatibility of existing static-key AES-CBC/AES-GCM jobs and ciphertext (including distinguishing a future versioned envelope from legacy ciphertext), KeyProvider vs. DataCipher responsibilities with `open`/`close` lifecycle, concurrency ownership and startup failures, envelope/data-key and rotation semantics with restart/restore behavior and no secrets in logs, errors, metrics or state, the module/dependency/shading boundary with a provider-free test double proving the no-per-row remote-call invariant, and a staged implementation and test plan. Please do not introduce a cloud SDK, a provider module, or a new public SPI in the first code change. Once the design proposal is ready, link it here so the compatibility and packaging contract can be settled before implementation starts. Looking forward to it. <!-- streview-comment:1848 --> -- 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]
