Activity for Info-ZIP project
-
Paul Marquess posted a comment on ticket #83
Thanks for taking the time to provide a patch for TIME_T_TYPE_DOUBLE. Confirmed that building the unzip 6.0 source with -DTIME_T_TYPE_DOUBLE does trigger a number of compilation issues. Although your patch does silence them, I see that the updates to the development source for unzip appear to have a fix for this issue -- it builds with any compilation errors. . With a very superficial look at the sources, I suspect your's my be the correct change. Won't know for sure until I run a few tests. One...
-
Taketo Kabe created ticket #83
unzip cannot be compiled with -DTIME_T_TYPE_DOUBLE=1 to make it Y2038 compliant on 32bit
-
Steven Schweda posted a comment on ticket #20
On Win 10 ( 32 bit ) computer ... Ok. Use WinRAR to decompress ... Not our program. Not our problem. Still more questions than answers. For example: "After decompression" of what? How was your (invisible) zip archive created? How do you know that there are ".exe" files in your original folder? How do you know that there are ".exe" files in your archive? Even if you were using our software, you would still need to provide some basic information, and you have not done that.
-
WinRAR is off-topic for this list. This forum is only for the Info-ZIP zip & unzip programs. It doesn't cover WinRAR Try uncompressing with unzip or 7z. If it fails with unzip, ask here again.
-
xx xxx posted a comment on ticket #20
On Win 10 ( 32 bit ) computer ... Use WinRAR to decompress ... .
-
> After decompression ... > No .exe file was found on the decompressed folder ... Before anyone can help you, you will need to provide some basic information about your environment(s), what you did, and what happened when you did it. Hardware? Software? OS/version? zip -v unzip -v Actual commands? Actual results? Copy+paste is your friend. "After decompression" of _what_? How was your (invisible) zip archive created? How do you know that there are ".exe" files in your original folder? How do you...
-
After decompression ...
-
Santiago Vila created ticket #82
zip: support for cross-compilation and large file support
-
zip: Two bugfixes and a dep8 test
-
zip: Sets 'version needed to extract' to 1.0 even if there are deflated files
-
zip: Charset conversion fails when zip is built with _FORTIFY_SOURCE
-
zip: fails to delete file from archive
-
zipnote: Segfault during write operation
-
zip: UTF-8 GPBF bit 11 is not set if "en_US.UTF-8" locale is not available
-
zip: CVE-2018-13410
-
--filesync is incompatible with --symlinks (symliks are always updated)
-
Cálestyo created ticket #9
add option to return a non-zero exit staus if -n was used and a file couldn't be extracted
-
tom235 posted a comment on ticket #42
it would be great if after a decade now we could apply this patch here ;-) WDYT?
-
unxed posted a comment on ticket #43
Similar fix suggested for Ubuntu's unzip: https://code.launchpad.net/~mitya57/ubuntu/+source/unzip/+git/unzip/+merge/466860
-
Comparing the first zipinfo listing with the most recent, the differences are the following fields offset of local header from start of archive minimum software version required to extract 32-bit CRC value (hex) compressed size uncompressed size All but the "minimum software version required to extract" you would expect to change if you've modified the file. The " minimum software version required to extract" has changed from 2.0 to 1.0, so I assume that is the one you are concerned with. classes5.dex...
-
Alex Mihail posted a comment on ticket #19
I guess it has become an episode of "how do I recreate this original file" more than anything being "wrong" per se. Let me illustrate it better. Here's the zipinfo -v of the classes.dex files inside a framework.jar - they are created with this "metadata" Central directory entry #53: --------------------------- classes5.dex offset of local header from start of archive: 39838572 (00000000025FE36Ch) bytes file system or operating system of origin: Unix version of encoding software: 2.0 minimum file...
-
[...] which looks to me like a bug, [...] CHANGES says that this was fixed in Zip version 3.1d03. Current development code (3.1e23) works correctly.
-
[...] requiring a minimum version of Zip 2.0 to extract ... however, I cannot seem to find this version existing anywhere, [...] So what? Which part of "minimum" is unclear to you? According to the APPNOTE: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT Version Needed To Extract = 2.0 for an archive member means that one of the following features was used: File is a folder (directory) File is compressed using Deflate compression File is encrypted using traditional PKWARE encryption I...
-
The term "version needed to extract" refers to the version of the zip specification and not the version of any zip/unzip implementation. See section 4.4.3.1 of APPNOTE.txt at https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt for the details. That then means you just need an unzip implementation that supports version 2 or better of the APPNOTE.txt specification. I'm not aware of any unzip implementation that doesn't support version 2 of the spec (which was written in the early 1990s) If...
-
Zip 2.0?
-
The patch itself
-
Thanks for the bug report! The Red Hat fix is present in the development version of zip.
-
newhoa created ticket #73
zip fails with non-latin unicode
-
Debian's 7zip just merged a fix for the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779207#51
-
There is a patched version of unzip that some of the Linux distros ship that allows the codepage/encoding to be specified. That deals with this use-case. In this case, , specifying codepage 866 with the -O option does the trick $ unzip -l -O cp866 Desktop.zip Archive: Desktop.zip Length Date Time Name --------- ---------- ----- ---- 0 09-28-2016 18:41 Новая папка/ 4 09-28-2016 18:40 Новый текстовый документ.txt --------- ------- 4 2 files
-
It looks like codepage 866, i.e. Cyrillic
-
What encoding is used for the filenames in Desktop.zip?
-
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232 Sample archive showing this bug attached.
-
The built-in .zip archiver in older versions of Windows used DOS (OEM) or Windows (ANSI) code page corresponding to current regional settings for new archives. Lots of such archives still exist. The correct behavior is to determine the relevant OEM or ANSI code page based on the system locale and use it. You can look at this PR for reference implementation: https://github.com/p7zip-project/p7zip/pull/232
-
Ta. I'll wait for the official gcc 14.1 & see if I can reproduce the error
-
Rudi Heitbaum posted a comment on ticket #72
This is on the development branch of LibreELEC (version 13.0) (Linux 6.6.29) and with gcc-14.1rc. I will be updating the dev branch to gcc 14.1 once it is formally released,.
-
Thanks Should have asked upfront, but what platform & C compiler are you running?
-
Hi Paul, without time.h - this is the error: timezone.c: In function 'mktime': timezone.c:644:18: error: invalid use of undefined type 'struct tm' 644 | save_isdst = tm->tm_isdst; | ^~ timezone.c:647:7: error: invalid use of undefined type 'struct tm' 647 | tm->tm_isdst = save_isdst; | ^~ timezone.c:661:11: error: implicit declaration of function 'localtime' [-Wimplicit-function-declaration] 661 | ltm = localtime(&then); | ^~~~~~~~~ timezone.c:44:1: note: 'localtime' is defined in header '<time.h>';...
-
Thanks Rudi. The changes to configure match ones we've already applied.
-
What error did you get that meant that you had to add #include <time.h> to timezone.c?
-
patch to compile with gcc-14.1
-
Takashi Yano posted a comment on ticket #30
Cygwin replaces these chars with unicode chars of 0xf000 | ch. Therefore, cygwin can treat these chars as a part of filename. Of course, they cannot be displayed properly outside cygwin.
-
Sam Tansy posted a comment on ticket #30
How do you want to create such files in windows?
-
I note that all of the issues listed have been addressed downstream by the main Linux distributions. Not necessarily all of them in each of the distributions, but at least there are fixes available. I have a couple of GH repos that have tried to collect all the variations of zip & unzip that are out in the wild. By no means complete, but it does show the fragmentation that has happened over the last few years. See nfo-ZIP-Family-Tree-for-Zip and nfo-ZIP-Family-Tree-for-UnZip) for more details. Having...
-
Neustradamus posted a comment on ticket #71
Dear @infozip team, @antinode2, @eewhite, @goathunter, @gordone, @roelofs, Can you answer to @allwit and me. There are a lot of CVEs never patched. In more, it will be nice to have an official InfoZip GitHub organization to contribute etc. Thanks in advance. Regards.
-
Dear @infozip team, @antinode2, @eewhite, @goathunter, @gordone, @roelofs, Can you answer to @kloczek and me. It is about all files and more: - https://sourceforge.net/projects/infozip/files/ Thanks in advance. Regards.
-
Peyton Zhong created ticket #71
when the next version 6.1 will be released
-
miskox created ticket #18
'custom' zip/unzip?
-
Ed Gordon posted a comment on ticket #69
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,...
-
Encryption enabled streaming
-
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.
-
Creating zip with Streamed Zip64 is missing central header records
-
Et7f3 posted a comment on ticket #31
The current codebase for 610b trigger those warnings: -Wformat-security -Wunused-const-variable -Wunused-variable -Wself-assign -Wformat here is a patch that fix some of those. You can find grep -r Info'(' | grep define to find other spot that trigger this warning. I wanted to fix with #define STRING "e" but I can't test on all OS so I let you test it.
-
Fix macOS build
-
Danilo Spinella posted a comment on ticket #65
Hi! We at openSUSE also are experiencing similar errors when using FORTIFY_SOURCE=3. You can try by compiling zip using -DFORTIFY_SOURCE=3 and using the following command line: $ touch α.txt $ zip a.zip α.txt openSUSE bug for reference: https://bugzilla.suse.com/show_bug.cgi?id=1200712
-
Sorry, the comment is broken with above patch...
-
[patch] Stop to replace some special characters in file name for cygwin.
-
Failure to properly handle archives with backward slashes under Linux
-
https://midnight-commander.org/ticket/4238 It's an upstream bug [...] Not on our tributary. It might be helpful if someone explained the actual situation in that other forum.
-
I need to apologize. Ok. unzip under Fedora 35 unpacks both archives with zero issues I can believe that. So, there's a bug: files in archive directories cannot be extracted by mask. Or, it's not a bug in UnZip, but you didn't treat "\" as a special character? Try "\\" instead of "\"? Using your other (smaller) example archive: proa$ ln -s ScreenRuler-v.0.8.1-Portable.zip SR.zip proa$ unzip -l SR.zip 'ScreenRuler-v.0.8.1-Portable\README.html' Archive: SR.zip Length Date Time Name --------- ----------...
-
I need to apologize. Ok. unzip under Fedora 35 unpacks both archives with zero issues I can believe that. So, there's a bug: files in archive directories cannot be extracted by mask. Or, it's not a bug in UnZip, but you didn't treat "\" as a special character? Try "\" instead of "\"? Using your other (smaller) example archive: proa$ ln -s ScreenRuler-v.0.8.1-Portable.zip SR.zip proa$ unzip -l SR.zip 'ScreenRuler-v.0.8.1-Portable\README.html' Archive: SR.zip Length Date Time Name --------- ----------...
-
Artem S. Tashkinov modified a comment on ticket #67
I need to apologize. unzip under Fedora 35 unpacks both archives with zero issues The issue is Midnight Commander which tries to parse unzip -l output and fails spectacularly: https://midnight-commander.org/ticket/4238 Still, I've identified a bug: $ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader\libEGL.dll' Archive: macintosh.js-win32-ia32-1.1.0.zip caution: filename not matched: swiftshader\libEGL.dll $ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader/libEGL.dll' Archive: macintosh.js-win32-ia32-1.1.0.zip...
-
I need to apologize. unzip under Fedora 35 unpacks both archives with zero issues The issue is Midnight Commander which tries to parse unzip -l output and fails spectacularly: https://midnight-commander.org/ticket/4238 Still, I've identified a bug: $ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader\libEGL.dll' Archive: macintosh.js-win32-ia32-1.1.0.zip caution: filename not matched: swiftshader\libEGL.dll $ unzip macintosh.js-win32-ia32-1.1.0.zip 'swiftshader/libEGL.dll' Archive: macintosh.js-win32-ia32-1.1.0.zip...
-
The current behavior of UnZip (or Apple's Archive Utility app) makes some sense, [...] More than I had realized. I apologize. Initially, I was too lazy to do the extraction; I just looked at a listing ("unzip -l"), and saw the backslashes. "Trust no one," I always say. So, today, I actually did the work, and noticed that UnZip apparently already handles this situation, which my tired, old brain had forgotten. Around here, on a Mac, for example: proa$ mkdir SR proa$ cd SR proa$ unzip6 ../ScreenRuler-v.0.8.1-Portable.zip...
-
As always, a program version number would be helpful, but it probably doesn't matter much in this case. unzip-6.0-53.fc35.x86_64 : https://src.fedoraproject.org/rpms/unzip/tree/rawhide One possible solution would be to enhance UnZip to convert "\" to "/" in the (path) names of archive members In my 25 years of using UNIX OSes I've not seen a single filename containing back slashes. I'd just go ahead and convert \ in filenames to / automatically but I'm not a C programmer. You might also complain...
-
As always, a program version number would be helpful, but it probably doesn't matter much in this case. unzip-6.0-53.fc35.x86_64 : https://src.fedoraproject.org/rpms/unzip/tree/rawhide One possible solution would be to enhance UnZip to convert "\" to "/" in the (path) names of archive members In my 25 years of using UNIX OSes I've not seen a single filename containing back slashes. I'd just go ahead and convert \ in filenames to / automatically but I'm not a C programmer. You might also complain...
-
unzip [...] As always, a program version number would be helpful, but it probably doesn't matter much in this case. unzip -v [...] doesn't properly handle archives with backward slashes under Linux. I just ran into this problem in a Ford/Microsoft SYNC software update kit a few days ago. If you try to unpack any of them, you'll get funny results. That depends on your sense of humor. One could argue about what "properly" means in this case. Such archives do not conform to the zip archive standard,...
-
Failure to properly handle archives with backward slashes under Linux
-
Bernhard M. Wiedemann posted a comment on ticket #25
There was a bug in the 1st scandir call param: "." vs n https://github.com/distropatches/zip/commit/5063c9ce12c58f2512c2d00080d863d14b5d31f7
-
I see that Mark Adler has addressed the zip bomb issue [...] That code is incompatible with the LZMA and PPMd code in the current development code, and it seems to have trouble with bzip2, too. Adding this feature to UnZip (for all supported compression and encryption schemes) is the current task, but I haven't had much time to devote to it recently. Some progress is possible, however. I would like an official organization and repository by product too, to have a better development and contributions....
-
I would like an official organization and repository by product too, to have a better development and contributions. I think it is very important to do it quickly, we are in 2021, soon in 2022. Linked to: - https://sourceforge.net/p/infozip/feature-requests/8/ - https://sourceforge.net/p/infozip/bugs/60/ - https://sourceforge.net/p/infozip/bugs/66/ Note that Mark Adler has done a fork here: - https://github.com/madler/unzip
-
I would like an official organization and repository by product too, to have a better development and contributions. I think it is very important to do it quickly, we are in 2021, soon in 2022. Linked to: - https://sourceforge.net/p/infozip/feature-requests/8/ - https://sourceforge.net/p/infozip/bugs/60/ - https://sourceforge.net/p/infozip/bugs/66/ Note that Mark Adler has done a fork here: - https://github.com/madler/unzip
-
I would like an official organization and repository by product too, to have a better development and contributions. I think it is very important to do it quickly, we are in 2021, soon in 2022. Linked to: - https://sourceforge.net/p/infozip/feature-requests/8/ - https://sourceforge.net/p/infozip/bugs/60/ - https://sourceforge.net/p/infozip/bugs/66/ Note that Mark Adler has done a fork here: - https://github.com/madler/unzip
-
I would like an official repo too, to have a better development and contributions. I think it is very important to do it quickly, we are in 2021, soon in 2022. Linked to: - https://sourceforge.net/p/infozip/feature-requests/8/ - https://sourceforge.net/p/infozip/bugs/60/ - https://sourceforge.net/p/infozip/bugs/66/ -
-
I would like an official repo too, to have a better development and contributions. I think it is very important to do it quickly, we are in 2021, soon in 2022. Linked to: - https://sourceforge.net/p/infozip/feature-requests/8/ - https://sourceforge.net/p/infozip/bugs/60/ - https://sourceforge.net/p/infozip/bugs/66/ -
-
Is it anywhere git repo with curent unzip code? No. Currently, Zip and UnZip source code is maintained privately by the maintainers. If not is it possible to create such repo on github or gitlab? (SF git frontend sucks) It may be possible, but we haven't decided to do it. What do you want to do? If you'd like, I could provide links to the latest available (2018) unreleased UnZip development code.
-
Tomasz Kłoczko created ticket #66
unzip project git repo?
-
[...] I downloaded the latest version of Zip again,that is Zip 3.0(dated 07-2008).But there seems to be differences in a few header files [...] "differences" between which kit and which other kit, exactly? Zip 3.0 should be Zip 3.0. Various Zip 3.0XXX beta kits were produced (some public, some private), but they should all have unique identification. Similarly, various Zip 3.1XXX beta kits have been produced (some public, some private), but they, too, should all have unique identification. If you've...
-
> [...] I downloaded the latest version of Zip again,that is Zip > 3.0(dated 07-2008).But there seems to be differences in a few header > files [...] "differences" between what and what, exactly? Zip 3.0 should be Zip 3.0. Various Zip 3.0XXX beta kits were produced (some public, some private), but they should all have unique identification. Similarly, various Zip 3.1XXX beta kits have been produced (some public, some private), but they, too, should all have unique identification. If you've linked...
-
Ashrita created ticket #17
Differences in header files
-
GIT repo
-
Tomáš Beránek modified a comment on ticket #64
The analyzed package was zip-3.0-27.fc33 (default version on Fedora 33 from the official repository https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-33&arch=x86_64). I wasn't able to find version zip31d on this site, only zip31c which seems to be the latest modified. I have checked the issues against this version and they are still present, but line numbers are a bit different. Updated line numbers: 1) unix/unix.c:343: error: Null Dereference When i was looking at the issue again, i noticed...
-
The analyzed package was zip-3.0-27.fc33 (default version on Fedora 33 from the official repository https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-33&arch=x86_64). I wasn't able to find version zip31d on this site, only zip31c which seems to be the latest modified. I have checked the issues against this version and they are still present, but line numbers are a bit different. Updated line numbers: 1) unix/unix.c:343: error: Null Dereference When i was looking at the issue again, i noticed...
-
The analyzed package was zip-3.0-27.fc33 (default version on Fedora 33). I wasn't able to find version zip31d on this site, only zip31c which seems to be the latest modified. I have checked the issues against this version and they are still present, but line numbers are a bit different. Updated line numbers: 1) unix/unix.c:343: error: Null Dereference When i was looking at the issue again, i noticed that for x == "//" the NULL dereference won't happen, but for x == "//host" or "//host/share" will....
-
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...
-
David Durgee posted a comment on ticket #65
Another point for you, I attempted to report this bug by the link http://www.info-zip.org/zip-bug.html but it results in an error about an empty README or some such.
-
buffer overflow detected during attempted recovery of zip
-
Results of the static analysis tool FB Infer on zip source files
-
Adam modified a comment on ticket #63
I read some other threads on this topic. It's not clear which path to take. I'm trying to handle archives with unicode characters regardless of the user's region. The error from unzip is "the specified files were not found". The archive file has Á in the name.
-
I read some other threads on this topic. It's not clear which path to take. I'm trying to handle archives with unicode characters regardless of the user's region.
-
Using Unzip to extract from archive paths containing true Unicode characters on Windows
-
Do not override command line settings during oem code page auto detection
-
Leonardo Herrera posted a comment on ticket #62
The sourceforge page contains download links that are also not working. Currently, there is no way to download zip / unzip for Windows. What I mean is, none of these links work: tug.ctan.org (US) [FROZEN] ftp.tex.ac.uk (UK) [FROZEN] ftp.dante.de (Germany) [FROZEN] I tried to compile it by my own using Visual Studio 2019 but haven't managed to do it. I cloned some mirror repository in Github and tried to use Actions to build it automatically, and almost got it. I think that could be a good course...
1 >
