Please let us know if you notice any problems with the site, or have any suggestions for further improvements.

We also fixed a few other issues that our users have reported. The complete list of changes in 5.7.3 is as follows:

• Fixed a crash connecting to some SFTP servers when the host key has changed
• Fixed a problem with -9807 errors on FTP with TLS/SSL connections
• Fixed a problem with MacBinary uploads to Rumpus and other servers with MacBinary support
• Fixed a problem with mirror downloads not deleting stray files
• Stopped invoking discrete graphics chip on newer MacBook Pros running Mountain Lion to conserve battery power

Fetch 5.7.3 is a free update if you purchased your Fetch license after January 28, 2009; otherwise an upgrade is $10, and a new license is $29.

Please download Fetch 5.7.3 from the Fetch Download page, or by choosing Check for Update… from the Fetch menu in an earlier version, and let us know what you think of the new release.]]>

We're pleased to announce that Fetch is compatible with cloud storage provider iKeepinCloud

iKeepinCloud offers 10GB of free, secure cloud storage, accessible to Fetch via SFTP or FTP with TLS/SSL. It can be used for backup, access to data on the road, and sharing files with other users.

The changes include:

• Added compatibility with the Gatekeeper feature of OS X 10.8 Mountain Lion
• Changed the Edit command to not open editor windows in front when Fetch is in the background
• Fixed a problem that caused crashes when the Fetch.log file could not be created
• Fixed a problem where an SFTP passphrase for a server using Two Factor Authentication was not hidden
• Fixed a problem where the modification dates of uploaded files were temporarily displayed in UTC
• Fixed a problem with using Preview as an editor on OS X 10.8 Mountain Lion
• Improved compatibility with Windows NT servers

For a complete list of changes, see the Fetch 5.7.2 Release Notes.

Fetch 5.7.2 is a free update if you purchased your Fetch license after January 28, 2009; otherwise an upgrade is $10, and a new license is $29.

Please download Fetch 5.7.2 from the Fetch Download page, or by choosing Check for Update… from the Fetch menu in an earlier version, and let us know what you think of the new release.]]>

Background

A Mac OS X application can be digitally signed by its developer. The digital signature functions as a wax seal: the developer's identity is securely inscribed in the application, and it becomes possible to detect if the application has been tampered in any way.

This is a good idea for a variety of reasons; for example, detecting that an application has been tampered with is a measure of protection against malware.

With this mechanism in place, it becomes possible for users to give special rights to an application (for example, the right to access the address book) and be sure that this right will not be hijacked by an impostor. This, too, is a measure of protection against malware.

Central to this mechanism, therefore, is the question of app identity: if I have two apps that claim to be different versions of the same app, should I trust them? If they really are different versions of the same app, then they should be extended equal rights. If, however, one of them is an impostor, then the two should not be given equal rights.

The solution Apple took to this question is that every signed app, in addition to its developer's identity, embeds a statement that describes precisely what conditions have to be met by another app in order for the other app to be considered merely a different version of the same app. This statement is known as the app's designated requirement.

Problem

Where we run into problems is that the designated requirement embedded inside an application signed by Xcode 4.3 using an Apple Developer ID (which is required to support Gatekeeper in Mac OS X 10.8 Mountain Lion) is too complex for Mac OS X 10.5.x to understand. As a result, a Gatekeeper-enabled app running on Mac OS X 10.5.x always seems to be an impostor, which results in a variety of problems (such as the user always being prompted to allow the app to use passwords stored in the keychain, instead of being prompted only the first time — exactly the problem we ran into with Fetch 5.7.1).

Obviously, then, the question is whether it is possible to create a designated requirement that is compatible with Gatekeeper but not too complex for Mac OS X 10.5.x to understand, thus retaining Gatekeeper support, but keeping Mac OS X 10.5.x happy.

The answer is: yes, if you are willing to require Mac OS X 10.5.8.

In Detail

Gatekeeper-enabled apps fail verification on Mac OS X 10.5.x for two different reasons:

• Understanding and verifying a Gatekeeper-compatible designated requirement requires support for some code signing features that were simply absent in Mac OS 10.5. There is nothing you can do about this, but since these features are present in Mac OS X 10.5.8, you can require your users to install the (free) update to Mac OS X 10.5.8. You are still left with a support burden, but it's not as bad as requiring a major upgrade. (We did not take the time to figure out exactly where in the 10.5.x release series this started working.)
• A designated requirement needs to be compiled before being built into an application. A Gatekeeper-compatible designated requirement compiled by Xcode 4.3.x on Mac OS X 10.7 is incompatible with Mac OS X 10.5.x and Mac OS X 10.6.x. However, the same designated requirement compiled on Mac OS X 10.5.8 is compatible with all later versions of Mac OS X. Therefore, if you compile your designated requirement on Mac OS X 10.5.8 and then embed it into your app using Xcode 4.3, you will produce a Gatekeeper-enabled app that is compatible with Mac OS X 10.5.8 and later.

Which all brings us to: why do you even care? Can't you just do what Daniel and Ken proposed and be done with it?

Well, you could. But if you do, you will expose yourself to the following two problems:

• When your Apple-issued developer certificate is renewed (its expiration time is no more than 5 years into the future), you will find that the app signed by the renewed certificate will not meet the designated requirement of the app signed by the current certificate. This is because Daniel and Ken used a designated requirement that is tied to a specific certificate, whereas our solution uses a designated requirement that is tied to our company identity.
• The Mac App Store version of your app and the Gatekeeper version of your app will not satisfy each other's designated requirement — again, because the designated requirement is tied to a specific certificate.

To understand the details of this, you need to look at what the designated requirement created looks like for an app distributed in the Mac App Store by a developer who has also been issued a Developer ID for Gatekeeper distribution:

[ 1]  designated => (
[ 2]    anchor apple generic 
[ 3]    and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ 
[ 4]  or 
[ 5]    anchor apple generic 
[ 6]    and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ 
[ 7]    and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ 
[ 8]    and certificate leaf[subject.OU] = some-developer-id
[ 9]  ) 
[10]  and identifier "some-bundle-id"

What this says is “The designated requirement (1) of this app is to have the bundle ID some-bundle-id (10) and either a) be trusted by Apple (2) and signed by Apple for App Store distribution (3) or b) be trusted by Apple (5) and signed by developer with ID some-developer-id (8) using their Gatekeeper certificate (6,7)”.

So, in short: you probably shouldn't use a trivial designated requirement tied to a specific certificate. Instead, you should:

1. Extract the full Gatekeeper designated requirement. If your app is on the App Store, download it from the App Store and extract its designated requirement; otherwise, build for Gatekeeper distribution using Xcode 4.3 and extract that designated requirement. To extract the designated requirement from your app, run “codesign -d -r-” on it, and save the “designated =>…” part of it to a file.
2. Compile the requirement on Mac OS X 10.5.8 (or the oldest version of Mac OS X that your app supports), using “csreq -r requirement.txt -b requirement.bin”.
3. Embed that compiled requirement inside your Xcode 4.3 build, using “codesign -r requirement.bin”.
4. Drop support for older minor versions of Mac OS X 10.5.

Much thanks to Ken and Daniel for giving me a starting point for figuring this out!

The changes include:

• Fixed a crash on Lion caused by the 3ivx video codec
• Fixed a problem that caused very slow file lists for folders with more than 10,000 items
• Fixed a problem with crashing on quit when StuffIt was installed
• Improved feedback during mirror and large transfer operations
• Changed SFTP behavior to honor SSH config settings, and no longer require a dummy password for connections using public key authentication

For a complete list of changes, see the Fetch 5.7.1 Release Notes.

Fetch 5.7.1 is a free update if you purchased your Fetch license after January 28, 2009; otherwise an upgrade is $10, and a new license is $29.

Please download Fetch 5.7.1 from the Fetch Download page, or by choosing Check for Update… from the Fetch menu in an earlier version, and let us know what you think of the new release.]]>

The specification for Bonjour enables discovery of file servers (such as FTP servers and SFTP servers), but does not provide any way for the server to inform other computers what type of security it uses. As a Fetch user, you might therefore be put in the annoying position of knowing that there is an FTP server on your local network, but have no idea what security setting to use to connect to it.

In response to our users’ requests, and in accordance with the specification for DNS Service Discovery Fetch 5.7 recognizes the keys auth and prot in the TXT record for an FTP server, with the following meanings:

• auth=MECH — connect to the FTP server using security mechanism MECH. Security mechanisms understood by Fetch 5.7 and later are GSSAPI and TLS.
• prot=LEVEL — in addition to connecting to the server securely, enable data security level LEVEL. Allowable security levels depend on the chosen security mechanism and the server implementation; Fetch supports security levels C and P for TLS and C, S, E, and P for GSSAPI.

Versions of Fetch prior to 5.6 behaved in one of two different ways when editing remote files:

• Ignore the user-specified preferred encoding — which annoyed many of our users
• Ignore the file-specified encoding — which annoyed many of our users

If you are using Fetch 5.6 or later in conjunction with BBEdit 9.2 or later, or TextWrangler 3.0 or later, then:

• If a remote file contains encoding information (such as am HTML META content-type tag), and you use Fetch to edit the file, the encoding information will be honored.
• If a remote file doesn’t specify its own encoding, then the preferred encoding from Fetch preferences will be used when you edit the file.

If you are using a different text editor, your results will vary; many editors ignore preferred encoding from Fetch preferences, and some ignore the encoding provided by the file itself. Feel free to contact the authors of your favorite text editor and request that they improve their cooperation with Fetch.

If you are a developer of a text editor, and you want to improve your integration with Fetch, please read the external editor protocol specification, and contact us with any questions.

Fetch now offers users better control over files. A simple but very useful way Fetch does this is by preserving the modification dates of uploaded files, making it easier to tell when a file on a server matches the local copy. Further, Fetch’s new Find field enables users to zero in on just the files they are working with.

Fetch now also helps users better monitor the progress of file transfers. While previous versions of Fetch reported the transfer progress of each individual file, it now displays the progress of the overall transfer, making it easier to see when the entire operation will be complete.

Finally, Fetch now makes it easier to use Fetch on multiple computers without having to manually update shortcuts on each one. Fetch introduces support for syncing Fetch shortcuts using Dropbox, enabling individuals and groups to access an up-to-date collection of shortcuts no matter which Mac they use.

Fetch 5.7 is compatible with Intel Macs running Mac OS X 10.5 or later, including Mac OS X 10.6 Snow Leopard and Mac OS X 10.7 Lion, and can be downloaded from http://fetchsoftworks.com or from the Mac App Store.

Fetch is free to try for 15 days, and a single-user license is $29. Upgrades are free for Fetch 5.5 and Fetch 5.6 users and customers who purchased Fetch after January 28, 2009; otherwise, upgrades are $10. Free licenses and upgrades are available for educational and charitable use.

The fixes:

• Added support for videos with missing MIME types
• Changed treatment of mute switch to be consistent with Videos app
• Fixed a bug that caused ads to be displayed incorrectly
• Fixed a crash when sharing a video by email
• Fixed a crash with QuickTime reference movies
• Fixed a problem logging into Radbox
• Fixed crash in tap-to-save on iOS 5.0b3
• Improved responsiveness while saving many videos
• Improved titles for videos found on Vimeo Watch Later page

Update today, and keep the feedback coming!