The trouble with quarantine

Lou Picciano loupicciano at
Fri Mar 15 10:55:40 EDT 2013


Beautiful! I'm glad you're bringing this up. 

Side note, at the application level: One way to get around this is to context-click the app in finder. That open command will bypass the GateKeeper checks... (I often find myself trying to get people onto the Terminal Command line, for its power and utility. hope you have better luck than I do!)

This approach doesn't help for the discrete library case, though, and it's a concern for any of us building software. In our case, we do custom builds of the PostgreSQL food chain; among other things, this leads to a de novo build of SSL and crypto libraries, then to libpq, the PostgreSQL client. Note that some build scripts for some software, savvy to all this, will do an 'attribute walk' in an attempt to account for this locally; still doesn't handle most distribution cases, though.

One solution to this is that the developer get himself an Apple Developer ID. Codesigning his packages with this ID will get them into the 'Identified Developers' club...

All this is further complicated when a user may have installed multiple versions of a given support library, at different places in the environment's tree: 'hey, the library is there!'  I imagine a given binary might skip a quarantined version of the lib, but find and execute the older (less feature-rich?) version further into the tree: 'I'm running Omnis, but my PG connection has no SSL!'

More fun? We've seen installers, however well-intentioned, change the local environment - including the library search paths, leading to some really unexpected - and hard-to-diagnose-at-a-distance - findings...
Bas, Thanks again for bubbling this up.

Yours in white-knuckle computing,


----- Original Message -----
From: Bastiaan Olij <bastiaan at>
To: OmnisList <omnisdev-en at>
Sent: Thu, 14 Mar 2013 22:30:12 -0000 (UTC)
Subject: The trouble with quarantine

Hi All,

I'm not sure if I wrote about this before but as I ran into it again
today and it may save a lot of people headaches I'll share this with

For many moons now, when you download something from the internet on Mac
OS X it gets marked to help prevent people from accidentally running
malicious software. When you start an application downloaded from the
internet you get a nice little message "this app has been downloaded
from the internet, are you really sure it is safe to run" or something
to that effect. If you answer yes the marker is removed and the
application will start.

If you download a ZIP file and then extract the zip file, the contents
of the zip file actually get the same marker.

Now with libraries the same thing applies but because the OS can't ask
you each time you start a library whether it is safe to run. A single
application may consist of a multitude of libraries (I'm not talking
about Omnis libraries here but dylibs, xcomps, etc).

So far this marker is pretty much ignored for libraries but we've
recently started running into situations, especially on OS X 10.8, but
also on several late 10.7 installs that libraries weren't being loaded.
I'm not sure what the trigger is but the approach does make sense, if
some malicous software manages to download and install some library you
don't want the OS to just load it up.

For us we ran into this downloading externals from the web, either new
xcomps from Tigerlogic or new xcomps from Brainy data. The ZIP files get
marked and when unzipped the xcomps get marked. Once the xcomps are
distributed to our clients those clients that have this protection
enabled suddenly had our application fail on them.

It's easy to fix though, after unzipping open up terminal and cd to the
location of the xcomp files. You can check if the marker is in place by
xattr myComponent.xcomp
If marked it will return:

To remove the marker simply run:
xattr -d myComponent.xcomp

Now the Mac OS X will load the xcomp just fine.


Manage your list subscriptions at

More information about the omnisdev-en mailing list