Ed Gordon

I'll have to look, but basic zip encryption is a funny thing. The original authors made some assumptions on how to do it, which were accepted by others. I'll try to look at this in the next week and refresh myself on what's going on. I believe the answer is driven by what information is available when during the encryption process. Given how weak basic zip encryption is, it probably shouldn't be used much now, except in cases where cracking is not much of a concern. Zip 3.1e, whenever that is finalized,...

This looks the same as bug #68. As noted there, the --force option seems to be working, but the code that creates the Zip64 headers is not being told to do that. Adding this bug to the queue of Zip bugs to work. It should be a fairly quick fix, but no telling when we'll get Zip 3.1 out with it.

The analysis looks right. The --force option seems to be working correctly, but the code that generates the Zip64 headers is not detecting that the headers are needed. And it does seem the same issue as #61. I'll throw this on the queue of issues with Zip that need to be fixed. It should be a fairly quick fix, but no promises when Zip 3.1 will be released with it. Thanks for the feedback.

We'll take a look at the zip-bug page. What version of Zip and what OS was the buffer overflow on? If you downloaded Zip, where did you get it? What command line did you use to create this? What can you tell us about the file being recovered (big, small, type)? If you can provide an example, without any sensitive data and small, that recreates the issue that would be very helpful. It's possible the latest beta fixed this issue already.

We'll take a look at that.

Sorry for the delay getting back to you. Where did you download this copy of Zip? Just want to confirm we are looking at the same package. Note that end providers, like Fedora, tend to edit our base packages before including them in their distributions. That said, we've made considerable modifications to Zip. Beta version Zip 3.1d should be on this site. Version Zip 3.1e hopefully should be hopefully posting in a month or so and should be close to being released as Zip 3.1. I'll check the latest...

The SourceForge version of the home page is up at http://infozip.sourceforge.net/. We'll need to look at what happened to the info-zip.org version. Yeah, things are getting old. We plan to get things cleaned up at some point, hopefully soon.

Good point. Zip knows where it's currently writing and so should be able to say if it was the work directory that ran out of space. We'll take a look and get back to you shortly. For reference, can you tell us what version of zip you are using ("zip -v")?