Don’t zip a file from a subdirectory

Don't zip a file from a subdirectory

10 Jan 2024

So today was a fun day at my university. I got the results back for my term project, and they were lower than I expected. When I made an inquiry into how my project was graded, I was told I didn't submit the source code in the zip file I submitted to the system.

I was confused because I was certain that I did. I downloaded the file onto my Android phone and opened it, and sure enough, the source code and another pdf file were in there. It looked like this:

I showed this to the TA, and he went to try to download the file again on his computer. He downloaded the file on Windows, and when he opened it, only a single pdf file (the final report) was extracted. I was suspecting it was due to some sort of Unix/Windows incompatibility, but he also tried it on an app on his iPad, with the same result.

At this point, I was suspicious of the system used for submissions. I opened my MacBook to try to unzip the file, double-clicked on it in Finder, and... the same thing happened!

Wondering if the zip file was corrupted, I used unzip -t to test the file. It was fine apparently.

$ unzip -t term-project.zip
Archive:  term-project.zip
    testing: report.pdf               OK
    testing: ../../implementation/src/notebook.ipynb   OK
    testing: ../presentation.pdf      OK
No errors detected in compressed data of term-project.zip.

Then I tried just unzipping the file using unzip. Heureka! The following warnings were printed:

$ unzip term-project.zip
Archive:  term-project.zip
 extracting: report.pdf              
warning:  skipped "../" path component(s) in ../../implementation/src/notebook.ipynb
 extracting: implementation/src/notebook.ipynb  
warning:  skipped "../" path component(s) in ../presentation.pdf
 extracting: presentation.pdf

When you give the path of the file to zip, it will be zipped using the path relative to the current directory. Turns out, this also applies to parent directories. While these are ignored when extracting files using the unzip utility, it appears the default desktop archive extractors on macOS and Windows silently fail instead.

Steps to reproduce

1. Create a directory structure like the following:

root
|--- notebook.ipynb
⌎--- final/
     ⌎--- report.pdf

2. Navigate to the final/ directory

$ cd root/final

3. Zip the report.pdf and notebook.ipynb files using the following command:

$ zip term-project.zip ../notebook.ipynb report.pdf

Bonus note

I tried to send the initial zip file to the TA using my university email, but it was not delivered. Then I tried Gmail on my phone, but the email failed to even be sent. Here is the error when I attempted to send it from my laptop:

I'm not currently sure why Google flags zip files with this characteristic, but since different zip extractors handle the zip file differently, perhaps there is or was some way to exploit this behavior for malicious purposes.

TL;DR: I zipped the files for my term project using the relative path from the subdirectory I was in, which caused the files from parent directories that were added to the archive to be silently ignored when unzipping.