Encrypt and compress json file #945
Open
Conversation
This file contains 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
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.
Related issue
Towards #932
Context / Background
We are currently developing the functionality of syncing the TTL data to Google Drive, related to #913.
When exporting the data, it would be good to encrypt it with a passphrase that the user enters into TTL (this will be optional, otherwise a TTL passphrase is used). If the user loads the data back into TTL, he has to enter the passphrase used before and then the data gets decrypted and imported into TTL (or the TTL passphrase is used for decryption).
What change is being introduced by this PR?
This PR introduces methods to de/encrypt and de/compress a file. This can be used during the exporting and importing of TTL data.
During the export, the file is first compressed then encrypted with a passphrase. During the import the file is decrypted first then decompressed.
For compressing, I used the compressing npm module. The file is compressed to .tgz. As the user is not supposed to decompress the file, I think the archive format does not matter that much.
For encryption, I used the cryptify npm module. I used the aes-256-cbc Cipher algorithm and utf8 encoding. The Cipher algorithm I choose was a rather arbitrary choice (the default algorithm used by cryptify) as I think we are using the encryption mostly to ensure the file is not changed (as discussed in #932). But cryptify offers a range of different cipher algorithms, so we could also change that.
How will this be tested?
I wrote unit tests for the new functions I implemented. But we definitely have to do more tests once the functionality is integrated with the sync-data-to-google-drive functionality.