(Note: zipaes was totally rewritten in version 1.1.)
zipaes is a set of tools for copying, archiving, and encrypting your data under Mac OS X 10.3 or later. Notable features include:
Most of the functionality comes from two command line tools: zipaes and rditto. Both are shell scripts which call on other tools built into Mac OS X, such as ditto and openssl. There is also a simple drag-and-drop utility called DropZipAES (an AppleScript which calls zipaes). Dragging files on it will create encrypted archives, and dragging encrypted archives on it will retrieve the files contained therein.
My own strategy has been to keep them all in the same folder, but use aliases or symlinks to make them available wherever I want. For example, I symlinked zipaes and rditto into /usr/local/bin and aliased DropZipAES onto the Desktop.
man pages for rditto or zipaes,
running either script without any parameters will cause it to spew usage notes to
stderr. The zipaes notes sort of assume you have already
had a look at the rditto notes. I will not duplicate those notes in this
documentation, but concentrate more on examples instead.
ditto, which can copy files from place
to place and also create archives of your data. One thing it is not good at doing is
copying to/from remote Macs, which is why I came up with rditto. rditto uses an
ssh connection to achieve this, so the data should be secure while in transit.
(Be sure to have Remote Login switched on in the Sharing preferences of the remote
computer.)
rditto is similar to ditto in many ways, but those familiar with the
latter should read the usage notes carefully, as there are some important differences. For example,
when rditto is copying files, it assumes that the last argument is always a
destination directory. Consider the following:
ditto foo bar
rditto foo bar
ditto will replace bar with foo.
rditto will copy foo into bar, resulting in bar/foo.
You cannot rename a file as you copy it using rditto.
The syntax for specifying files on remote hosts is similar to what you find in other tools like
scp and rsync. These two lines copy a directory called bar
within /foo to and from a remote host, showing the file-by-file progress with
-V:
rditto -V /foo/bar/ user@remote.host:/foo/
rditto -V user@remote.host:/foo/bar/ /foo/
As a rule, you should always end directory names with a trailing slash.
There are times when rditto uses the slash to distinguish between files and
directories, which is necessary due to some peculiarities of ditto. (Specifically,
it checks for the slash after source paths on remote hosts, since it is cumbersome to examine
remote files up close.)
rditto can also archive files directly to a remote volume. This time, we back up
to and restore from to a zip file at the other end.
rditto -ck /foo/bar/ user@remote.host:/foo/bar.zip
rditto -xk user@remote.host:/foo/bar.zip /foo/
rditto uses pipes internally to handle these remote connections,
but you can use them in inventive ways yourself. For example, many Internet providers give
you some space on a web server to set up a home page. Let's say yours asks you to upload the
page to a www directory using ftp. You could post bar to the web
by writing something like this:
rditto -ck /foo/bar/ "-" | curl -T "-" -u
user:password ftp://homepages.isp.com/www/bar.zip
You could then use either a web browser or curl and rditto once
again to download file:
curl http://homepages.isp.com/~user/bar.zip | rditto -xk "-" /foo/
(Note: Depending on the ISP, the ~ may or may not be necessary.)
Unlike the regular ditto, rditto allows you to combine several
items into a single archive, as in:
rditto -ck foo/ bar/ foobar.zip
This involves creating temporary copies of foo and bar which are
eventually deleted after the archive has been created. (These copies go into the
Temporary Items folder of your home folder, so make sure you have enough disk space
left on that volume.) By default, the copies are deleted with a simple rm instruction, but
you can choose to securely delete them using the -r# option.
-r0, -r1, -r2, and -r3 correspond to
rm (simple unlink), srm -s (single pass overwrite),
srm -m (7 passes), and srm (35 passes), respectively.
Alternatively, you can have rditto create one archive for each item using the
-b batch mode:
rditto -ck -b ".zip" foo/ bar/ dest/
This should result in dest/foo.zip and dest/bar.zip.
As you can see, -b expects the suffix that goes with the archives.
zipaes is basically just a layer on top of rditto, the syntax
is much the same. Since it only creates encrypted zip archives, you can drop the
-k option. The only added consideration is in how to provide the password to
be used in encrypting and decrypting the data. The default behaviour is to have
openssl (the encryption tool used by zipaes) prompt you for it
itself. This is arguably the most secure approach, but it can be awkward at times.
In particular, if you have turned on verbose mode (-v or -V),
the password prompt can appear at the most inopportune moment and be obscured by comments.
Fortunately, openssl provides other means of entering the password, and zipaes
lets you specify the one you want using -p. (The only one you must expressly
avoid is stdin, since that is reserved for the archive data.) You can enter it
directly on the command line or via an environment variable.
zipaes -c -p pass:shazam foo/bar/ bar.zipaes
zipaes -x -p pass:shazam bar.zipaes foo/
password="shazam"; export password
zipaes -c -p env:password foo/bar/ bar.zipaes
zipaes -x -p env:password bar.zipaes foo/
The second form should be a bit more secure than the first (as long as you don't keep that
environment variable alive), as someone logged into your computer could easily eavesdrop on
what you are typing into the command line using ps. (Environment variables are
only accessible by the shell which exported them and any child processes.)
zipaes also lets you enter -p env without specifying the variable
name. In this case, zipaes itself will prompt you for the password, which it
will then pass on to the to openssl through an environment variable. From an
outside perspective, this works much like the default password prompt from openssl, but plays
nicer when you have verbose mode on.
Note that when you are addressing remote hosts, you may see a second password request coming
out of ssh. If you do a lot of remote copying and archiving, you might want to
look into setting up public keys and ssh agents. (Read man ssh-keygen and
man ssh-agent to set it up yourself or try a third party utility like
SSH Agent.)
Make sure your archive names end in “.zipaes”. DropZipAES looks for that to determine if the file is an archive to be expanded or a file to be compressed.
If you open up AppleScript in Script Editor, you will see a number of user-defined properties at the top you can edit to customize the behaviour somewhat.
| request_destination | Always ask you where you want to put things. By default, the archive goes into the same folder as the original files, though DropZipAES may ask you for the destination anyway if there is any ambiguity. |
|---|---|
| use_Terminal |
Normally, DropZipAES runs zipaes in an internal shell, but you can
elect to have it open Terminal windows to execute commands. The main motivations
for doing this would be to see a more verbose output and/or to use a more secure
password entry. (DropZipAES normally just calls zipaes with the
password on the command line.)
|
| zipaes_options | These are options to add to the zipaes command line. The default is "-r1", which has DropZipAES to a quick overwrite of temporary copies of your data as a security precaution. In conjunction with use_Terminal, I like to use "-r1 -V -p env" so that I can watch everything that's going on. |
| beep_when_done | This only comes into effect when use_Terminal is false, but that tends to be when you need the most feedback about script completion anyway. |
I basically rewrote everything. I had this tool calledrdittokicking around, and it occurred to me one day that I should combine the functionality ofzipaesandrdittoand it would really kick arse. A lot of the time, I like to archive stuff to another networked computer, and now I can create encrypted backups over there with a single command. How cool is that?The mind-meld between the two tools inevitably led to some changes in usage, so I'll go over the main differences for those who got used to 1.0.x.
- There is no
unzipaestool anymore. From now on, usezipaes -cto create archives andzipaes -xto expand them.zipaesno longer deals with unencrypted zip archives, except that it can convert between encrypted (.zipaes) and unencrypted (.zip) versions through the-zoption. All other .zip file operations are handled byrditto.-rno longer deletes the source files. (I found that was a bit too much of a liability.) It only applies to the temporary files, so it is now more like-tr. Moreover, I simplified the syntax so that you now just specify a score from 0 to 3, depending on how thoroughly you want to the temporary files deleted.-pnow uses theopensslcolon-delimited format for password entry.I will try not to have another big shake-up like that, and apologize for the inconvenience.
This usually means you entered the decryption password wrong, but it could also mean the archive got corrupted.
Yes. They do not check if the destination path is already occupied, so be careful.
I double-quote file paths, so white space characters should be safe, though there
may be some special characters like “$” which are still interpreted in
special ways by the shell. Also, stay away from the likes of “/” and
“:&rdquo. I ran into some file names containing a date of the form
“mm/dd/yyyy” which caused me grief.
Apparently, OS X turns slashes in the Finder into colons behind the scenes, and
rditto looks for a colon to delimit the remote host from the path.
In the current implementation, password strings are not quoted (because the quotes were somehow getting incorporated into the encryption keys and causing confusion). This may eventually change, but for now, avoid white space characters and other characters (e.g. “$”, “*”) which might be interpreted by the shell in special ways.
Not directly. You could decrypt the archive first and usezipinfoto have a peek.(Thezipaes -xz foo.zipaes foo.zip
zipinfo foo.zip | grep -v __MACOSXgrepcommand filters out the sequestered Mac meta-data from the listing, which tends to be a distracting nuisance in this case.)
I don't recommend it. zipaes was meant for smaller data sets you can quickly archive or unarchive in their entirety, so there should be no need to micro-manage the contents. For larger backups, you might consider setting up a disk image with Disk Utility. (These can be encrypted in the same way as zipaes archives.)
Yes. If you are using thezipcommand line tool, you can specify encryption with-e. There are two reasons why I chose not do this:
- I am not using
zip, but ratherditto(so that I can create Finder-compliant zip archives), and the latter does not give you the-eoption.- I trust open source encryption algorithms more than proprietary ones, and zip's internal implementations are proprietary. In fact, there are at least two different algorithms in use (depending on whether you use the PKZip or WinZip engine). I just don't wanna go there...
v1.1 |
|
v1.0.4 |
|
v1.0.3 |
|
v1.0.2 |
|
v1.0.1 |
|
v1.0 |
|