-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore: Handle incorrect encryption key #5284
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @manishrjain and @parasssh)
worker/restore.go, line 58 at r1 (raw file):
Previously, parasssh wrote…
keyfile is optional. Just return the err.
But the error would be Invalid Header
. This doesn't give any valid information to the user.
worker/restore.go, line 60 at r1 (raw file):
Previously, parasssh wrote…
Dont need this whole comment. Just the first sentence will suffice.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @manishrjain and @parasssh)
worker/restore.go, line 58 at r1 (raw file):
Previously, jarifibrahim (Ibrahim Jarif) wrote…
But the error would be
Invalid Header
. This doesn't give any valid information to the user.
The actual error returned is
gzip: invalid header
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @manishrjain and @parasssh)
worker/restore.go, line 58 at r1 (raw file):
Previously, jarifibrahim (Ibrahim Jarif) wrote…
The actual error returned is
gzip: invalid header
Ok. But the keyfile is optional. And if it fails for other reasons then it will confuse the error. Maybe do this error only if keyfile is non-nil.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @manishrjain)
worker/restore.go, line 58 at r1 (raw file):
Previously, parasssh wrote…
Ok. But the keyfile is optional. And if it fails for other reasons then it will confuse the error. Maybe do this error only if keyfile is non-nil.
Ah! I see what you mean. I've made the change. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @jarifibrahim and @manishrjain)
a discussion (no related file):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jarifibrahim and @manishrjain)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jarifibrahim and @manishrjain)
Jira - DGRAPH-1281 and DGRAPH-1282 When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key. When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key. This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file. (cherry picked from commit 25c37c8)
Jira - DGRAPH-1281 and DGRAPH-1282 When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key. When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key. This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file. (cherry picked from commit 25c37c8)
Jira - DGRAPH-1281 and DGRAPH-1282 When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key. When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key. This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file. (cherry picked from commit 25c37c8)
Jira - DGRAPH-1281 and DGRAPH-1282 When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key. When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key. This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file. (cherry picked from commit 25c37c8)
Jira - DGRAPH-1281 and DGRAPH-1282 When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key. When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key. This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file.
Jira - DGRAPH-1281 and DGRAPH-1282
When the restore is started, we open a badger instance with the provided encryption key and then check if the backup file can be opened using the encryption key. If the backup cannot be opened using the encryption key, we return an error to the user but the badger DB stores the encryption key.
When the user tries to restore the same backup to the same badger instance without a key (because backup is unencrypted), badger complaints about the missing key.
This PR fixes by opening badger after opening the backup file. This ensures we don't open an encrypted badger db for an unencrypted backup file.
This change is![Reviewable](https://camo.githubusercontent.com/1541c4039185914e83657d3683ec25920c672c6c5c7ab4240ee7bff601adec0b/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)