Failed to unzip after build is made in VM

[etrubek]

Issue Occurs since version 2.1.6. After building the zip in the VM, unzipping it fails on the following error: 
java.io.FileNotFoundException: /tmp/app/10000243/code/913aece8-2086-4464-9482-6cf626d5a5b1/static/css/6.447b365d.chunk.css (No such file or directory)

Additional info

• Commands used inside the VM: nvm use 12.14.1 npm install npm run build:zip

• Script commands from json package: "scripts": { "zip": "cd build && npx bestzip bundle.zip * && cd ..", "build:zip": "cross-env npm run build && npm run zip" }

• After building the zip using the same commands from local env the unzipping works fine.

[nfriedly]

I'm not sure; 2.1.6 improved symlink support, are there any symlinks in your build directory?

Can you get a tree listing of what's in /tmp/app/10000243/code/913aece8-2086-4464-9482-6cf626d5a5b1/ after the error occurs?

Can you download the zip from the VM and unzip it locally? Or upload a locally built zip to the vm and try unzipping it there?

Also, just for clarification, are you saying it worked on 2.1.5 and stopped working in 2.1.6 (released a couple of months ago), or are you saying it worked in 2.1.6 and stopped working in 2.1.7 (released last week)?

Here's the changes for 2.1.6: https://github.com/nfriedly/node-bestzip/compare/v2.1.5...v2.1.6

And, for 2.1.7: https://github.com/nfriedly/node-bestzip/compare/v2.1.6...v2.1.7

[etrubek]

• Not sure regarding the symlink.
• I’ll try to get listing tree of the content in the attached path.
• I’ve already uploaded a locally built zip to the VM and unzipped it there with success.
• Clarification, I’m saying that it occurs since 2.1.6. I know this because 2.1.5 works fine and 2.1.6 doesn’t. This happened after I run ‘npm audit fix’ and this bumped the version from 2.1.5 to 2.1.7.
 After that it stopped working so I lowered the version to 2.1.6 and it still didn’t worked and then I lowered to 2.1.5 and it did work. Hence the issue starts in 2.1.6.

[nfriedly]

FWIW, if that's your only use of bestzip, then it's not vulnerable to the issue fixed in v2.1.7. It's only a concern if you pass unfiltered user input to it as filenames. So you could roll back to v2.1.5 and ignore that specific advisory.