Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[wallet] Reopen CDBEnv after encryption instead of shutting down #12493
Shutting down the software was to prevent the BDB environment from writing unencrypted private keys to disk in the database log files, as was noted here. This PR replaces the shutdown behavior with a CDBEnv flush, close, and reopen which achieves the same effect: everything is cleanly flushed and closed, the log files are removed, and then the environment reopened to continue normal operation.
To ensure that no unencrypted private keys are in the log files after encrypting the wallet, I wrote this script to pull private keys from the original wallet file and searches for these keys in the log files (note that you will have to change your file paths to make it work on your own machine).
As for concerns about private keys being written to slack space or being kept in memory, these behaviors no longer exist after the original wallet encryption PR and the shutting down solution from 2011.
It'd be a little tricky to test the threadsafeness in a unit test. I think you'd need to insert hooks that would allow the test to block threads at particular points. If you want to test in a more ad-hoc way, though, I think you could do this by inserting a sleep in
I manually tested that there were indeed private keys in the logs after encrypting with the environment reload commented out, tested that reloading the environment does remove the logs with a lightly modified version of @achow101's script PierreRochard@e9cd31c
NB: I think I found a bug when setting the thread safety test up, the default wallet and a loaded wallet which are in the same directory will be in two different environments because the