Failed to unzip after build is made in VM
etrubek opened this issue · 3 comments
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.
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: v2.1.5...v2.1.6
And, for 2.1.7: v2.1.6...v2.1.7
- 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.
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.