Ujjwaljain16 commented on issue #37842: URL: https://github.com/apache/superset/issues/37842#issuecomment-3903247968
I’ve done a deep dive into this and believe I’ve found the root cause. `EncryptedType` is currently initialized with a static value of `SECRET_KEY` at model import time. That means the encryption engine can stay permanently bound to the old key, even after rotation. During re-encrypt-secrets: Decryption with PREVIOUS_SECRET_KEY succeeds Re-encryption uses the model’s existing EncryptedType If that instance still holds the old key, the data gets written back unchanged The command exits successfully but effectively does nothing After restart with the new SECRET_KEY, decryption fails which matches what everyone is seeing. The fix is to pass a callable instead of a static string: ```python EncryptedType(*args, lambda: app_config["SECRET_KEY"], **kwargs) ``` `sqlalchemy-utils` supports this natively and resolves the key on every encrypt/decrypt call, so it ensures the correct key is always used at runtime. I’ll open a PR with this change and updated tests shortly. -- 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]
