Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Install a newer verison of zip with encryption support UNIX
I get a lot of client files that are compressed with zip on a PC. In addition, they are often encrypted with a password. I have been attempting to phase out Stuffit for the last year -- but unfortunately, I still have it around for the sole purpose of opening these encrypted zip files.

Double-clicking these encrypted zip archives will (by default) open the BomArchiveHelper, and generate an error. The standard /usr/bin/zip install that comes with Mac OS X 10.4 does not support encrypted zip files. So I decided to set out to compile a newer version of zip -- thinking that replacing the binary in /usr/bin might allow for double-clickable encrypted zip archive compression.

Of course I didn't really think it through -- in the sense that you would need some facility for entering a password in the BomArchiveHelper application, and that does not appear to exist. So basically, my attempts at enabling the default BomArchiveHelper to open encrypted zip files failed. However, in the process, I was able to build a better CLI version of zip that does indeed support encrypted archives. So while I can't double-click these encrypted zip archives, I can decompress them using the terminal, which is fine by me. I can finally dump Stuffit.

The process for compiling zip from source is pretty straightforward. The first thing you'll need to do is get the newest version of zip from the project page. Get the regular zip program, version 2.31, from near the bottom of the page. Put the downloaded package in a new folder (I'll use one called zip-231 on my Desktop in the example below). Open the Terminal, and type the following commands (lines starting with # are comments; don't type those lines!):
 $ cd ~/Desktop/zip-231
 $ unzip zip231.zip

 # make
 $ make -f unix/Makefile generic_gcc

 # install into /usr/local/bin
 $ sudo make -f unix/Makefile install

 # for some reason the man pages don't install
 # so install manually
 $ sudo cp man/zip.1 /usr/local/man/man1
After that, you can use the new version of zip to install password-protected zip archives.

[robg adds: I haven't tested this one...]
    •    
  • Currently 2.14 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (7 votes cast)
 
[36,468 views]  

Install a newer verison of zip with encryption support | 21 comments | Create New Account
Click here to return to the 'Install a newer verison of zip with encryption support' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Install a newer verison of zip with encryption support
Authored by: goatbar on Sep 30, '05 08:52:15AM

You can also use fink or darwin ports...

-kurt



[ Reply to This | # ]
Install a newer verison of zip with encryption support
Authored by: efs on Oct 24, '05 03:17:44PM

Well, I went to the Zip page to see how to download the newer version, and then was reading about Darwin... but I'm not sure I understood it. In fact, I'm pretty sure I didn't. And the 'make' command isn't recognized... so what am I missing?

I wanted to create backup file, compressed if possible, that have a password on them. I am currently using DMG, which supports a password, but not compression. A PKZip version that supports encryption sounded great.

Thanks.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: friedmaj on Sep 30, '05 08:53:13AM

Am I missing something about Stuffit? It seems to do its job perfectly well.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: PanicRoom on Sep 30, '05 11:47:07AM
There are various problems which annoy different people. My biggest headache with Stuffit is that it's a proprietry format: files I've 'stuffed' can only be unstuffed with Stuffit. This isn't usually too much of a problem, though there are scenarios where it becomes a pain. A few months ago, I tried accessing a large, segmented file from a backup I created several years ago. For some strange reason, the current version of Expander refused to identify all the segments as belonging to the same file. I dug out the old version of Stuffit Lite which did the original compression but, oops, Classic not installed on the new iMac. Dug around some more in a couple of boxes and found my old PB540C running OS8, booted, ran Stuffit Lite, successfully decompressed my archive, (marvelled at how cool my old Powerbook still was!) then packed everything back into boxes.
If I didn't still have legacy hardware (and original software) lying about, then I would have been screwed. If [Aladdin] Alume ever goes out of business and stops releasing versions of Stuffit which are compatible with new OSs, then you might as well kiss two decades worth of backed-up data goodbye.

[ Reply to This | # ]
What's wrong with Stuffit
Authored by: Cerberus on Sep 30, '05 12:01:28PM

The above comments are very succinct and germain. My only addition would be that StuffIt is a PURCHASED tool, BOM is a tool integrated to the OS so it is 'free' once I have a legal copy of the OS. The slient points about proprietary formats are VERY worrysome...



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: unresort on Oct 01, '05 01:24:13AM

i am gonna have to call bullsh*t on this comment. i mean, seriously, do you shun all proprietary formats for fear that you won't be able to open something 5-6 years down the line? that's just stupid. so, you don't save anything from Photoshop as a .psd? i guess .ai files are out too. what about .doc files? .toast?

dude, i think the real issue is WHAT are you going to want to open again say, 5 years from now?

the format is legit and it works, don't trash it just because you can. it makes you seem petty.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: silverdr on Oct 01, '05 02:49:19AM

C'mon. Think thoroughly about this what you just wrote again... and no, I am not the only one who disagree with you.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: flakaddict on Oct 04, '05 11:17:24PM

I, for one, would like those formats to be open too. If .doc were open, I could seamlessly use it in OpenOffice. .ai and .psd files as well, would be great if those were open so caomptibility with the Gimp could be ensured.

Stuffit's got two options, just like anyone else competing with open source products: improve your products, or corner the market in such a way you're trapping people.

Microsoft seems to have chosen the latter...heh.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: doneitner on Sep 30, '05 05:18:21PM

It's always nice to know one's options and how to get helpful updates like this. Thanks for the tip.

As to Stuffit's usefulness... as a format Stuffit is proprietary. Zip was too for many years (PKZip and all that). But as a program, Stuffit seems to do the job very nicely; it supports more formats than just its own so there's no need to use the proprietary Stuffit format even if using the Stuffit program. It's like using WinRAR on Windows -- it still supports Zip so no need to use the also proprietary RAR format.



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: hamarkus on Oct 04, '05 05:39:41AM

I do not understand why the fact that one option of Stuffit is to compress files into a proprietory format would speak against using it to decompress zip files.
It is a very well functioning, stable and free product.

Ok, having it will litter your applications folder with one more item and you have to update it seperately from the OS (but which you have to do for self-build zip programs as well).



[ Reply to This | # ]
What's wrong with Stuffit
Authored by: silverdr on Oct 01, '05 03:13:16AM

Several things are wrong with it. 1. It's a third party add-on and not a part of the stadard OS distribution. 2. It's commercial. 3. It promotes thair proprietary formats (still so many people distribute their products as .sit or even .sitx archives rather than Apple recommended disk images). 4. It is being marketed by an arrogant company which charges the users of the platform it grew up on just about double the price of the Windows users and doesn't even bother to reply to e-mail whenever there is a "difficult" question to answer in it... The list could continue for a while. OTOH I have to admit that it's a very good product.



[ Reply to This | # ]
beware of resource forks
Authored by: wallybear on Sep 30, '05 10:36:01AM

What about resource forks? Apple's zip will keep them, but this new one?



[ Reply to This | # ]
beware of resource forks
Authored by: danielj7 on Sep 30, '05 03:07:26PM

No, Apple has modified Tiger's command line programs--like zip, tar, cp, and rsync--to handle resource forks and other filesystem metadata. Any version you compile yourself or install with Fink or Darwinports won't have this support. You'd have to modify the source yourself to use Tiger's new *xattr family of functions.



[ Reply to This | # ]
beware of resource forks
Authored by: sjk on Sep 30, '05 03:45:04PM

The zip command on 10.4 doesn't preserve resources forks and extended attributes. "Create Archive of ..." in Finder does because BOMArchiveHelper uses the ditto command to create zip archives. That's my understanding anyway, which I can't double-check right now.



[ Reply to This | # ]
beware of resource forks
Authored by: silverdr on Oct 01, '05 03:17:31AM

It shouldn't matter much as long as one uses command line version only for unarchiving the passwd protected files, which by default don't come from a resource-fork enabled filesystem. But your remark does have a valid point of course.



[ Reply to This | # ]
beware of resource forks
Authored by: sjk on Oct 01, '05 11:16:50PM

Are you referring to kaih's comment? Your reply is threaded with wallybear's comment.



[ Reply to This | # ]
beware of resource forks
Authored by: vykor on Apr 26, '06 06:05:08PM

Apple's default command-line zip doesn't seem to retain resource forks as of 10.4.6. I ran into this just now, as two files sent to me, zipped via the command line zip utility, were without resource forks. Testing the command line version seemThe man page has a -df switch description, which seems to imply that resource forks would be kept unless -df is on. That line is misleading: even if you try to use -df, it appears have no effect at all on the compression behavior.

This is different from gzip and bzip2 in Tiger, both of which preserve metadata. And of course, ditto, which is probably the preferred way to generate resource-fork friendly archives, rather than zip.

The built-in zip has no encryption, apparently not resource fork aware, and the zipcloak utility is also a placebo only. If it weren't for system stability purposes, I would have just overwritten them with a newly compiled copy.



[ Reply to This | # ]
10.4.2 zip/unzip already does this...
Authored by: kaih on Sep 30, '05 06:47:13PM

AFAIK, the built in version of zip, at least in 10.4.2, has password support.
I was sent a zip file yesterday that double-clicking on in the finder didn't work. I went to the Terminal and ran "unzip /path/to/file.zip" - it started unzipping, prompted me for a password and then continued once I entered the correct password.

YMMV...

---
k:.



[ Reply to This | # ]
10.4.2 zip/unzip already does this...
Authored by: zygote on Sep 30, '05 11:27:24PM

What about creating encrypted zip files? Does the standard version of Zip or this "new" allow that?



[ Reply to This | # ]
10.4.2 zip/unzip already does this...
Authored by: henry on Oct 01, '05 05:55:09AM

The version of zip included in 10.4.2 is "Zip 2.3+CAN-2004-1010 (November 29th 1999)". This doesn't support creating encrypted zip files, but the current version of the software does (I just tried it).

I also tested the included version of unzip ("UnZip 5.51 of 22 May 2004"), and it is able to unzip an encrypted zipfile.

So 10.4.2 as standard can unzip encrypted archives, but not create them.



[ Reply to This | # ]
10.4.2 zip/unzip already does this...
Authored by: whom on Oct 01, '05 01:43:06PM

I compiled and tested encryption (zip2.3.1 using -e option) and got the message:

zip error: Invalid command arguments (encryption not supported)

How did you get it to work?



[ Reply to This | # ]