Feature/password protected zip #79
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
src/main.rs
Outdated
| @@ -73,6 +73,11 @@ struct UnzipArgs { | |||
| #[arg(short = 'd', long, value_name = "DIRECTORY")] | |||
| output_directory: Option<PathBuf>, | |||
|
|
|||
| /// Password to decrypt encrypted zipfile entries (if any). | |||
| /// Encryption is assumed to be the ZipCrypto algorithm. | |||
There was a problem hiding this comment.
Are you sure this sentence is correct? It looks to me as though the underlying library supports either ZipCrypto or AES encryption.
I'm wondering about the pros and cons of adding a test for AES encryption too. Pros: thoroughness. Cons: it's really a test of the underlying library, not ripunzip, and it might require enabling additional features in it.
Overall, if you've any doubt about whether AES is supported, please add a test! Otherwise, don't bother - but please clarify this doc comment either way.
Sorry for not spotting this on the first pass.
There was a problem hiding this comment.
All good, this was a good pickup. Thank you.
I've clarified the doc comment.
I've opted not to add a test for AES encrypted zipfiles because v0.6.3 of the zip library (current version used) doesn't seem to have an easy interface to do this (compared to the newer v2.2). I also didn't want to include a pre-made zip file because it's a bit suspicious finding a random zip file in source code.
I have tested it separately though - i.e. using the binary on a aes encrypted zipfile - yes it does work.
|
Thanks - merging! I'll make a new release sometime in the next few days. |
Fixes #62