Avoid reading the whole file into memory when adding a file to a .zip archive

[gave92]

Resolved / Related Issues
Items resolved / related issues by this PR.

• For Feature: Improve support for compressing and decompressing archives #45

Details of Changes
Add details of changes here.

• Avoid reading the whole file into memory when adding a file to a .zip archive

Unfortunately this requires some trivial changes to SharpZipLib which currently does not support opening a ZipOutputStream to an existing archive. Modified nuget package added to the project, like it was done for microsoft.management.infrastructure.runtime.win

To test: copy a 1GB and paste it into a .zip archive. See Files.exe memory not-growing anymore to 1GB :)

Validation
How did you test these changes?

• Built and ran the app

[d2dyno1]

Does this fix zip bombs?

[gave92]

My understanding is that zip bombs are about extracting archives, this reduces memory usage when compressing files.

[gave92]

But now I'm curious to test what happens extracting the famous 42.zip in Files, let's see ;)

[gave92]

Ah nevermind: those kinds of zip bombs only work if you try recursively unzip nested archives (which we don't). This one (non recursive) works though: https://www.bamsoftware.com/hacks/zipbomb/. It's a 42Kb file that gets expanded to 5Gb, but the only consequence is that you occupy some disk space (and you can stop extraction at any moment).

[yaira2]

@gave92 would it make sense to switch to using 7zip?

[gave92]

@yaichenbaum we can look at integrating 7zip through e.g SevenZipExtractor. I suggest we still merge this as it's beneficial for FTP too. Bundling a custom SharpZipLib is also not too bad if it's temporary (till we switch to 7zip).

[d2dyno1]

@yaichenbaum I'm going to review it next weekend. If you want to, you can review it now.

[d2dyno1]

From initial look, it looks ok!