Should we also disable the option to enable encryption on an existing datastore and ask them to instead try backup/restore?
Yes. That will be caught by badger as “Encryption Key Mismatch” and panic. @ibrahim can we return an error instead so dgraph can propagate a useful log and exit gracefully?
Also, I realized even the mechanism to “change” an encryption key is not clean. It needs to be exported and then live-loaded onto an alpha with the new key. Bulk/Restore assumes same key for encryption and decryption.
Summarizing
Fixes:
- Allow Bulk/Restore to have enc-key and dec-key. (Paras). This will allow changing keys and removing encryption.
- exit dgraph gracefully when error on key. (Paras)
- badger to send error when key mismatches. (Ibrahim)
- More tests (Ibrahim and Paras)
Badger is returning an error. We’re not handling it gracefully in dgraph
@balaji: we have to update the blog linked above to correct the steps for encrypting an unencrypted installation cc: @LGalatin
Created this Jira: https://dgraph.atlassian.net/browse/DGRAPH-1572
@balaji Pointed out that encryption can be enabled in badger using the rotate
tool. I wrote a test to confirm this Add a test for rotate tool by jarifibrahim · Pull Request #1343 · dgraph-io/badger · GitHub.
So the badger encryption blog can be updated to show that encryption can be enabled on an unencrypted DB using the rotate tool.