Activity for Steven Schweda
-
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.
-
> 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...
-
[...] 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...
-
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 --------- ----------...
-
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...
-
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,...
-
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....
-
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.
-
[...] 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...
-
Did you get a chance to push your changes into the build? [...] The change is in the development code, so it should be in the next release, but I still don't have a date for that.
-
Can you please confirm about unzip 6.1 official release timelines? or any planning related to release of unzip 6.1 ? I haven't done much with it lately. Still no real schedule, but I have been trying to get some work done on it lately. If I were more definite, it'd be mostly lies.
-
Is there any update on when we could download the unzip binary with the fix for this issue? Nothing good. There's now one more problem in the queue, and I haven't found much time to work on them lately. But slow progress continues.
-
Is any firm schedule to release unzip 6.1 this year or any expected time has been decided? Nothing's firm or decided. There are some remaining problems with exotic names on Windows, and this new "zip bomb" thing to deal with. It should come out this year, but it probably should have come out last year, too.
-
[...] I therefore suspect this may be a bug in Mac OS instead. [...] User error is more likely. echo *.pdf If you want Zip to see: *.pdf as a command-line argument, then you need to prevent your shell from "globbing" it (that is, expanding the "*" wildcard). An easy way to do that is to quote any special globbing characters ("*", "?") using apostrophes. For example: zip -r dir.zip directory/ -x '*pdf' Otherwise, Zip (or "rsync", any other program) will see the results of the shell's wildcard expansion,...
-
[...] I therefore suspect this may be a bug in Mac OS instead. [...] User error is more likely. echo *.pdf If you want Zip to see: *.pdf as a command-line argument, then you need to prevent your shell from "globbing" it (that is, expanding the "" wildcard). An easy way to do that is to quote any special globbing characters ("", "?") using apostrophes. For example: zip -r dir.zip directory/ -x '*pdf' Otherwise, Zip (or "rsync", any other program) will see the results of the shell's wildcard expansion,...
-
[...] I therefore suspect this may be a bug in Mac OS instead. [...] User error is more likely. echo *.pdf If you want Zip to see: *.pdf as a command-line argument, then you need to prevent your shell from "globbing" it (that is, expanding the "" wildcard). An easy way to do that is to quote any special globbing characters ("", "?") using apostrophes. For example: zip -r dir.zip directory/ -x '*pdf' Otherwise, Zip (or "rsync", any other program) will see the results of the shell's wildcard expansion,...
-
[...] I therefore suspect this may be a bug in Mac OS instead. [...] User error is more likely. echo *.pdf If you want Zip to see: *.pdf as a command-line argument, then you need to prevent your shell from "globbing" it (that is, expanding the "" wildcard). An easy way to do that is to quote any special globbing characters ("", "?") using apostrophes. For example: zip -r dir.zip directory/ -x '*pdf' Otherwise, Zip (or "rsync", any other program) will see the results of the shell's wildcard expansion,...
-
May i know when would the next build available for public with the fix for the below bug? Not known. As soon as I figure out a pending problem with exotic (but non-Unicode) file names on Windows, it should follow pretty quickly. But I don't know when that will happen.
-
You are an absolute gem ! If that were true, then you would never have had the problem. Thanks again for the report and the testing.
-
This appears to be what did it: unix/unix.c: /* 2014-03-10 SMS. * Changed to create multiple directory levels, as needed. The new ("new") code didn't consider "/". There's a revised unix/unix.c here: http://antinode.info/ftp/info-zip/unzip610c23/unix/unix.c_sf_bug_56 The changes seem plausible (to me), and the result seems to work in my quick tests. If you could beat on it for a while, and let me know what catches fire, I'd be grateful. If you don't break it, then the changes should appear in the...
-
[...] with -d "/" the files in the zip archives are not uncompressed to "/", but are getting uncompressed to the current directory. Thanks for the report. I can reproduce it. It looks like an unintentional behavior change someplace between 6.00 and 6.1c23. I'll look into it.
-
Can we know the expected date of UNZIP 6.1(unzip.exe) release? I don't know. There is no firm schedule, and we're looking at some bugs in the handling of non-ASCII characters on Windows. Hopefully this Unzip 6.1 Major release will contains fix for this vulnerability [...] The next beta kit (6.1c) should have that fix. Eventually, the real 6.1 should have it, too.
-
How can I build InfoZip (Unzip 6.x) on Mingw/Msys2.. [...] The secret is hidden in INSTALL (under "Win32 (WinNT or Win9x)": [...] for mingw32 and CygWin, GNU Make and win32\Makefile.gcc should do the job. [...] So, a command like the following should work: make -f win32/Makefile.gcc On the bright side, with the next UnZip beta release (6.1c), the standard Unix build procedure should work as expected in MinGW. (Basically, "-DUNIX" is replaced by "-DWIN32", but there were also some other changes to...
-
Thanks for the report and the patch. I've made the change in the development code. so it should appear in the UnZip 6.1 release.
-
Thanks for the report. There was a buffer overflow detected in list.c file where cfactorstr[] had an insufficient size (10). It was fixed in unzip beta versions and expanded to size 12 but I think it's still insufficient. The right size should be 13 (sgn (1), int (10), % (1), nul (1)). The secret is that the result of compr_fract() is (approximately) divided by ten (for rounding) before it gets used as "cfactor". Look for expressions like: cfactor = (cfactor + 5) / 10; So, I believe that 1+9+1+1...
-
Thanks for the report and the suggested patch. Using unzip 6.10b, it is possible to extract files from an unencrypted archive even when the "-P" parameter is used. The fundamental problem with this complaint is that there is no such thing as "an unencrypted archive", only an encrypted member of an archive. It's perfectly legal to mix encrypted members and unencrypted members in a single archive. When a user supplies a password (interactively, or using -P), UnZip will use it when it sees an encrypted...
-
I use zip32.dll Version 2.32, Date 1. July 2006, on Windows 7 64bit, German Region Settings I know very little about Windows, the Zip DLL, or exotic character encodings, but... I would start by looking at Zip version 3.0 (July 5th 2008). There are also public beta versions up to Zip version 3.1d-BETA (November 15th 2015). (And if 3.1d isn't good enough, then the Zip maintainer might be willing to provide an early (pre-beta) 3.1e kit.) Zip 3.1d claims to offer Unicode support, which might be helpful...
-
Thanks for report. For many other reasons, that whole "try: [...]" suggested-command...
-
Using zip old.zip --out new.zip --copy -i myfile.txt Im able to copy a file from...
-
Thanks for the report. I've never studied this (old) code closely, so I know nothing,...
-
When I compare the zipinfo of the two files (org new and patched new), the order...
-
Thanks for the additional data. It appears that the difference you're seeing between...
-
Thanks for the additional data. It appears that the difference you're seeing between...
-
To investigate this properly, some basic information would help: Computer type and...
-
Thanks for the report. But... [...] zip archives produced by various other tools,...
-
Thanks for the contribution, but the current released program versions (Zip 3.0,...
1
