MacOS – John the Ripper and sparsebundle password help

I've done some testing, and can offer a (hopefully) authoritative answer.

Short answer: the versions are stored on the same disk (or disk image) as the actual file, so versions shouldn't leak information outside of your encrypted image. But there might be another leak, see below.

Long answer: Versions creates an invisible folder at the top of each volume, named ".DocumentRevisions-V100" with an internal structure like this:

.DocumentRevisions-V100
    .cs
        ChunkStorage    (this is presumably used to store chunks of large files that didn't entirely change between versions)
    AllUIDs             (this is only created on disks that have permissions ignored)
    ChunkTemp
    db-v1
        db.sqlite      (this is the primary index of document IDs, etc)
    PerUID             (this is only created on disks that have ownership respected)
        501            (documents created/owned by user #501)
        502            (etc...)
    staging            (???)

For info on the sqlite index and the background daemon that mediates access to it, read John Siracusa's excellent review at ars technica.

The document versions themselves are stored in subdirectories in either AllUIDs or PerUID/youruserid. Under that, each versioned document gets its own subdirectory, numbered starting at 1. Under that is a single folder named "com.apple.documentVersions", and under that, each revision is stored as a separate document (unless it's broken into chunks -- I haven't experimented with large documents) named with a UUID and type extension. For example, if I (user #501) edit a rtf document on my boot volume and save several revisions, they might be stored as:

/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/0787B7C3-DE11-4065-9FD9-61870212011D.rtf
/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/D533CF36-0D49-4910-B0EB-C92395C05726.rtf

If I then opened another rtf file and saved a version of it, it might be named:

/.DocumentRevisions-V100/PerUID/501/2/com.apple.documentVersions/74A6EF6E-A22A-4196-B560-40ABDBF46DF4.rtf

If I saved it on my SecretDocs image (mounted with ownership ignored), versions would be stored like:

/Volumes/SecretDocs/.DocumentRevisions-V100/AllUIDs/1/com.apple.documentVersions/2ED4DAFD-9BCF-4158-BFDB-F9EEC631E44A.rtf

BTW, permissions on the version files seem to be cloned from the original files. Permissions on the enclosing folders tend to allow execute only (i.e. you can't see the filenames, but if you know the file's name you can access it). For example PerUID/501 is set to allow execute only for user 501, no access for anyone else. The db-v1 folder only allows root access. Without investigating in detail, it seems to be pretty locked-down.

Now, about that other leak I threatened you with: Lion apps tend to save their state when you quit, so if you have a confidential document open when you quit, some of its information (like I think a screenshot) may get stored in ~/Library/Saved Application State/someappid.savedState. As long as you close before saving I think you're safe here.

No, you aren't doing anything wrong. Apple doesn't allow you to paste into certain secure dialog boxes. It's a feature, not a bug. (It makes a brute force hack of the dialog box more difficult.)

You can paste the password into the command line if you mount the secure image using hdiutil.

Open Terminal and type:

 hdiutil attach /path/to/imagefile -stdinpass

When prompted for the password, copy it from a text file or (preferably) a password vault and paste it into terminal.

If the path/to/imagefile is complex, you can type the command, a space, then drag the imagefile icon from the finder into the terminal window to automatically enter the path/filname.