Skip to content

Implementing a db key validity check on starting the encrypted fs #57

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

Merged
merged 1 commit into from
Nov 30, 2021

Conversation

scottmmorris
Copy link
Contributor

@scottmmorris scottmmorris commented Nov 30, 2021

Description

There needs to be a more explicit way of determining if the db key is valid for the encrypted fs. At the moment, the efs start up continues until it tries to decrypt existing state and cannot because the key is not valid.

To overcome this, a similar pattern to sentinel species will be used. On creation of the efs, we encrypt a known string into the db at the root level. Then on subsequent constructions, we access the string and if we cannot decrypt it then we know that the vault key is invalid and we therefore throw an error. If the string does not exist in the db then we start and put the known string in because we know its a new db.

Tasks

  1. Implement the key validity checks
  2. Add new testing for the key validity checks

Final checklist

  • Domain specific tests
  • Full tests
  • Updated inline-comment documentation
  • Lint fixed
  • Squash and rebased
  • Sanity check the final build

@scottmmorris scottmmorris merged commit cd5be7f into master Nov 30, 2021
@CMCDragonkai
Copy link
Member

This is cool!

But we realised we should probably do this against the js-db instead so that everything benefits from this. In js-db it would have to create a "_meta" level just for this stuff though and safeguard so that users don't try to create a level like so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development
Development

Successfully merging this pull request may close these issues.

2 participants