search

chrissimpkins / crypto

Simple symmetric GPG file encryption and decryption
http://chrissimpkins.github.io/crypto
MIT License
48 stars 27 forks source link

tar archive support (--tar) for directories #3

Closed chrisidefix closed 9 years ago

chrisidefix commented 9 years ago

I added basic tar archiving support for folders before encryption. I know this could be done through other tools before using crypto, but for large folders it is very convenient to have it build right into crypto, since the user now doesn't have to wait for the tar archive creation to complete before starting the encryption.

For example, imagine you want to encrypt 100 folders, each 10 GB large. I could (and did) write a script, which would first tar the folders for me and then call crypto/gpg to do the encryption. The problem half-way down the line, I would have to enter the passcode for the encryption, which is inconvenient if I just want to start a larger batch-job. Building this into crypto allows me to first enter my passcode, then create the tar-archives and encrypt them right thereafter.

I also delete the tar archives after the encryption is done. Let me know what you think. Cheers.

chrissimpkins commented 9 years ago

thanks much for submitting this Chris. Really appreciate it. Let me take a look through it and write some tests. will include in the next release.

chrisidefix commented 9 years ago

One thing I wasn't sure about how to handle, was if such a 'tar' option should only tar folders and not also files. I decided against this, since simply creating a tar archive would not compress the file and not really add any real benefit. It would take more resources and the whole encryption process would take longer. The only good reason I could come up with to tar files as well, would be to hide the original file-name inside an archive.

Something else to think about is storage space. Right now ALL folders are packed into tar archives first. They are then encrypted, before the temporary tar files are being removed. The problem is that this approach at the worst time doubles the required amount of hard-drive space. Anyway, hope this is useful for someone else.

chrissimpkins commented 9 years ago

Will be merging this later today to start testing it. Aiming to release this with your filename anonymity suggestion as v1.4.0 (Issue #5). Were you interested in coding the latter as well?

chrisidefix commented 9 years ago

Yes, already did the mayor part on the implementation - but I realised that using the --use-embedded-filename option is not an ideal solution, since it creates issues when decrypting files inside folders as only the actual filename, not original path is stored inside the encrypted file. Now I wrote a simple parser to decrypt the filename separately and set then manually set this as the output name (similar to as you did previously). I'll create a pull-request later-on and rebase onto the development branch with your latest changes I guess.