The logins rename reseals every payload under the new table name - #406
Merged
Conversation
An encrypted column's AAD is "<table>.<column>". e3a9c7d1b5f4 renamed harness_logins to provider_logins and left every payload sealed under the old name, so every pre-existing login failed with SecretDecryptError on refresh and on use. The migration now decrypts each row under the old name and re-encrypts it under the new one, in both directions. A migration test seeds a row under harness_logins, runs the upgrade, and decrypts it under provider_logins. Fresh rows encrypt under the new name, so the existing suite could not see the break. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
e3a9c7d1b5f4renamesharness_loginstoprovider_logins.ProviderLogin.payloadis anEncryptedJsonField, and its AES-GCM AAD is<table>.<column>. Every row written before the rename is sealed underharness_logins.payload; the model now opens withprovider_logins.payload, so GCM authentication fails and every pre-existing login raisesSecretDecryptErroron token refresh and on use. Fresh rows encrypt under the new name, so CI could not see it.Fix
The migration decrypts each
provider_logins.payloadunder the old AAD and re-encrypts it under the new one, right after the rename. Downgrade does the reverse. Both usedruks.secrets.utils, so the same configured keys apply.Audit of the other provider migrations:
a4c8e2f7b913andc9d1e3f5a7b2rename nothing that carries an encrypted column.harness_logins.payloadis the only encrypted column any migration has renamed.Verification
Checked by hand against a scratch database: upgrade to the revision before the rename, seed a
harness_loginsrow sealed under the old AAD, upgrade to head, decrypt under the new AAD. Without the reseal step this raisesSecretDecryptError; with it the payload reads back. The downgrade reseal was checked the same way.conftest._OWN_DATABASE_MODULESdrops the staletest_harness_login_persistencename fortest_provider_login_persistence, which the earlier rename left behind.docs/development.mdnotes that renaming a table or column with an encrypted field needs this step.Gates
ruff check/ruff format --check: cleanpytest backend/: passed🤖 Generated with Claude Code