Expand-7Zip creates zero-length file when password is missing or incorrect

[JasonFossen]

Hello:

When a 7z archive is encrypted with a password, but the -EncryptFileNames switch is not used, then a zero-length file is created when expanding with either no password or the wrong password. The name of the file created (with zero bytes in it) is taken from the 7z archive.

For example, if a file named FOO.TXT has 1KB of text in it, then it is successfully encrypted like this (notice, no -EncryptFileNames switch):

Compress-7Zip -Path .\FOO.TXT -ArchiveFileName .\PlainFileNames.7z -Format SevenZip -Password "DasP@sswurd"

The the following command fails to extract the contents of FOO.TXT as expected:

Expand-7Zip -ArchiveFileName .\PlainFileNames.7z -TargetPath . -Password "WrongPassword"

But the above command does create a file named FOO.TXT that has zero bytes inside of it. This also happens when no -Password is given at all.

Even worse, if FOO.TXT already exists in the target path with contents, that existing file will be overwritten by the zero-length file.

This is unexpected and dangerous. When attempting to expand files from an encrypted archive and the decryption fails, then 1) no files should be created and 2) no existing files should be overwritten.

Note that when the encrypted archive is originally created with the -EncryptFileNames switch, and the expansion later fails because of an incorrect password, then no existing files are overwritten and no zero-length files are created. This should always be the behavior when decryption fails.

Cheers,
   J.

[thoemmi]

Hi @JasonFossen,

unfortunately, I cannot fix this issue in my code. 7Zip4Powershell is just a shim around SevenZipSharp, a managed wrapper for 7-Zip. It takes the parameters from Powershell and passes them to that library.

So the problem is located in that wrapper. Unfortunately, that project seems to be abandoned. Because of that @tomap created a fork at Github. At the moment I don't have time, otherwise I'd file an issue there and create a unit test.

Anyway, currently there's nothing I can do about it in 7Zip4Powershell.

[JasonFossen]

I totally understand, it does take a lot of time, you've been very generous!

One quick solution for 7Zip4Powershell is to make the -EncryptFileNames switch automatic whenever a -Password is supplied and the format is SevenZip (then eliminate the switch entirely). This is more secure, eliminates the zero-byte file overwrite problem (with SevenZip format archives), will make all the Pester tests pass (I'll update the Pester tests related to -EncryptFileNames), and would require changing only a few lines of code in 7Zip4Powershell.

Until the SevenZipSharp project is updated, though, for the sake of safety, it would perhaps be better if Compress-7Zip and Expand-7Zip did not support password-encrypted Zip format files at all (since Zip format files are incompatible with -EncrypteFileNames). When -Password is specified, require the SevenZip format, as mentioned above. This unfortunate change would at least only require a few code changes... :-\