False positive for zip files

[danielpclark]

Using unzip will exit early with a false positive.

As noted above, the -P option may be used to supply a password on the command line, but at a cost in security. The preferred decryption method is simply to extract normally; if a zipfile member is encrypted, unzip will prompt for the password without echoing what is typed. unzip continues to use the same password as long as it appears to be valid, by testing a 12-byte header on each file. The correct password will always check out against the header, but there is a 1-in-256 chance that an incorrect password will as well. (This is a security feature of the PKWARE zipfile format; it helps prevent brute-force attacks that might otherwise gain a large speed advantage by testing only the header.) In the case that an incorrect password is given but it passes the header test anyway, either an incorrect CRC will be generated for the extracted data or else unzip will fail during the extraction because the ``decrypted'' bytes do not constitute a valid compressed data stream

This can be fixed in one of several ways.

1. After alleged success result verify that files have been created/modified since the app started (this may not be that great of an idea do to because of Rust's SystemTime types flaws.
2. PREFERRED METHOD: Create a temporary directory and extract contents to that (tempdir). Then check if the directory has files when ever a successful extraction is reported. This feature would be much better is the temporary directory is a Virtual Disk in RAM.
3. Integrate unzip code directly and re-implement the decryption without the false positives
4. (this may not work for AES encrypted zip files depending on visibility into contents) unzip will list the file contents it possesses. We may be able to use that to compare the resulting output.

[danielpclark]

I just finished with the command line status false positive. And I've found unzip has implemented another false positive of empty files made of the correct file names. 🤦‍♂️