DanielLeens commented on issue #12407:
URL: https://github.com/apache/seatunnel/issues/12407#issuecomment-6168242325

   Thanks for offering to take the initial design work. That scope is 
available, but it should remain a design/STIP discussion before any provider 
implementation starts.
   
   I rechecked the current implementation: `FieldEncrypt` still requires a 
direct `key`, discovers an `Encryptor` lazily from the transform path, and the 
SPI only exposes `init(String key)` plus encrypt/decrypt operations. There is 
no open KeyProvider implementation PR. That means the first deliverable should 
define the compatible boundary rather than add a provider or vendor SDK.
   
   Please start a focused design proposal and cover at least:
   
   1. How existing static-key AES-CBC/AES-GCM jobs and already-produced 
ciphertext remain compatible, including how a future versioned envelope is 
distinguished from legacy ciphertext.
   2. The KeyProvider versus DataCipher responsibilities, lifecycle 
(`open`/`close`), concurrency ownership, startup failures, and the rule that 
remote key access is never on the per-row path.
   3. Envelope/data-key and rotation semantics, plus restart/restore behavior 
without placing keys or credentials in logs, errors, metrics, or serialized 
state.
   4. The module, dependency, and shading boundary, including a provider-free 
test double that proves the lifecycle and no-per-row remote-call invariant.
   5. A staged implementation and test plan: compatible static-key refactor 
first, one reference provider only after the design is accepted, then 
additional providers.
   
   Please do not add a cloud SDK, a provider module, or a new public SPI in the 
first code change. Link the design discussion here so the community can settle 
the compatibility and packaging contract first.
   


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