Posted a quick refresh of Quarantino here on the website. Still need to get these apps notarized but we're at least on the modern 64-bit runtime! Download in the usual places...

As it turns out, Application bundles containing so-called FAT binaries (in this case 32/64-Bit x86 and x86-64 architectures) are not eligible for notarization through Apple's gatekeeper notary service. At least this is the case for binaries built after June 2019. In any event, I have thinned the Quarantino package so that it contains only x86-64 code and now it's been notarized and as such, conveniently installs on Catalina (10.15). It should run on systems as early as 10.8. If you, for some reason, need even earlier support, the original 32-bit version (Gatekeeper approved) is available for download here.

Labels: 32-bit, 64-bit, gatekeeper, quarantine, security macos, Universal Binary

If you want to see an example of the fragile base class problem in action, just run one of the, I dunno, 20 or so Cocoa applications I wrote in Xcode (from 2007-present) on Sierra. I spent a lot of time ensuring they were bug-free on 10.6-10.10. Here's a hint: new design idiom, new base classes. Don't be trying to staple new underwear onto the baby.

For a comparand, I have 16-bit Windows applications I wrote in 1989 that still run in the WOW layer. This is why Microsoft rules the corporate desktop and no amount of clever advertising (throwing shade) is going to change that. Sadly.

But I guess you win some and you lose some: yesterday I learned that iMovie '11 runs perfectly on Sierra. For certain jobs, it's my tool of choice (4:3 small and fast m4v files).

Labels: gatekeeper

New 'Dok' malware targets Macs using signed Apple developer certificate: "The code, dubbed "Dok" by security firm Check Point, is said to affect "all versions" of macOS/OS X, and be the first "major scale" malware directed at Mac owners through a "coordinated email phishing campaign." The emails are aimed mostly at Europeans, one example being a German-language message from a supposed Swiss official, claiming problems with the target's tax return."

Revoke! Revoke! Remote delete! Remote delete?

Labels: gatekeeper, quarantine, security policy

Technical notes, my online memory: Gatekeeper, XProtect and the Quarantine attribute: "Apps can opt-in to Gatekeeper and Xprotect protection by adding LSFileQuarantineEnabled to their Contents/Info.plist. This means that any files created by that app will get tagged with the apple quarantine HFS+ extended attribute.

Everything you wanted to know about quarantine but were afraid to ask.

Labels: gatekeeper, quarantine, secure coding mac, security

The Cocoa Distillery - How to build on 10.8 and earlier, then sign for...: "The only way to obtain a v2 signature is by code signing under 10.9, but since Xcode 3 doesn’t run on anything newer than 10.6.8, I’ll have to separate the build process from the signing, packaging and submission process."

For those building under 10.6.8 for the Mac App Store or Gatekeeper.

Labels: codesign, gatekeeper, secure coding mac, security, version 2 signature

Technical Note TN2206: OS X Code Signing In Depth: "Checking Gatekeeper Conformance
To test Gatekeeper conformance, you must use OS X 10.9.5 or later. Follow these steps:

Package your program the way you ship it, such as in a disk image.
Download it from its website, or mail it to yourself, or send it to yourself using AirDrop or Message. This will quarantine the downloaded copy. This is necessary to trigger the Gatekeeper check as Gatekeeper only checks quarantined files the first time they're opened.

Hint: keep the downloaded .dmg around; it will stay quarantined and you can use it again and again to test.

Drag-install your app and launch it.
Observe the results.
Hint: Don't launch from inside the .dmg."

A quick guide to testing Gatekeeper conformance under 10.9.5

Labels: gatekeeper

Issue 156 - soundflower

OK, I seem to have found a fix for this. The problem seems to be that the installer gets 'quarantined' because of an unrecognised certificate. This is marked against the file by an extended attribute. You need to clear the attribute to allow the installer to run again. The command for this is:

xattr -c

The installer will run after this. It throws up a certificate error but you can tell the system to trust it. For some reason, the install ran completely clean...

More about the xattr command at developer.apple.com.

Labels: gatekeeper, quarantine bit

Apple - OS X Mountain Lion - It's built to keep your Mac safe.
Gatekeeper makes it safer to download apps by protecting you from inadvertently installing malicious software on your Mac. The safest place to download apps for your Mac is the Mac App Store. Apple reviews each app before it’s accepted by the store, and if there’s ever a problem with an app, Apple can quickly remove it from the store."

User friendly description of Gatekeeper and Developer ID.

Labels: developerid, gatekeeper, mountain lion

As I previously wrote (Apple codesigning Certificates), Xcode 4.3 generates a reasonably complex designated requirement when code signing your application for Developer ID and Gatekeeper.

However, independent testing with the spctl --assess command demonstrates that kinder, simpler designated requirements (even code signed with Xcode 3.2.5) will be approved by Gatekeeper.

After reviewing the WWDC2012 DeveloperID and Gatekeeper video on iTunesU, it would appear that the function of these elaborate designated requirements are as follows:

That applications distributed through the Mac App Store and applications distributed via Developer ID which have the same bundle Identifier will be treated as the same application by the system, with respect to sandboxed files, keychain access and preferences etc.

If your application uses the Keychain, or stores critical information in Prefs, you will want to sign your code with the designated requirements generated by Xcode 4.3 (or higher).

It should be possible to generate the designated requirements with Xcode 4.3 and back-port them to Xcode 3.2.5 (in my case, my DeveloperID-distributed code is a Universal binary and includes PowerPC code which cannot be generated by LLVM 3.0).

Labels: designated requirements, developerid, gatekeeper, lion, mountain lion

Bundle was signed with this leaf certificate:
certificate leaf[subject.CN] = "Developer ID Application: Gen Kiyooka"

NUMBER COMMON NAME
0 Developer ID Application: Gen Kiyooka
1 Developer ID Certification Authority
2 Apple Root CA
designated requirements = anchor apple generic
and identifier "com.genkiyooka.developerid"
and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */
or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
and certificate leaf[subject.OU] = MQK467HD9A)


Presumably for changes coming with Gatekeeper, Xcode 4.3 generates more elaborate designated requirements for codesigned Mac applications, depending on whether the signing certificate is a DeveloperID (internet distribution), MacDeveloper, or 3rd Party Mac Developer certificate (App Store submission).

I'm no x509 expert, but it appears that Apple has defined some certificate extensions for use in it's code signing certificates and the new designated requirements are referencing fields within the certificate extensions.

In particular, field.1.2.840.113635.100.6.1 is the prefix for constant kSecOIDAPPLE_EXTENSION_CODE_SIGNING and field.1.2.840.113635.100.6.2 is the prefix for extension constant kSecOIDAPPLE_EXTENSION_INTERMEDIATE_MARKER.

While these new designated requirements are certainly fancy, they are by no means required for DeveloperID codesigned applications to run under Gatekeeper. At least not the Gatekeeper simulation available under Lion.

REFERENCES:
x509 certificate extensions at stackoverflow.com
libsecurity_keychain/CertificateValues.cpp at opensource.apple.com

Labels: codesigning, developerid, gatekeeper

Gatekeeper vs. Leopard: an ongoing tale — Fetch

XCode 4.3 generated designated requirements for Gatekeeper and Developer ID.

[ 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""

SOURCE: fetchsoftworks.com

Labels: codesigning, designated requirements, gatekeeper

Securosis Blog | OS X 10.8 Gatekeeper in Depth

An nice article about the quarantine bit and how it interacts with Gatekeeper and Developer ID under Mountain Lion.

Labels: developerid, gatekeeper, mountain lion, quarantine bit

App Sandbox Design Guide: Migrating an App to a Sandbox

To support migration of app support files when a user first launches the sandboxed version of your app, create a container migration manifest.

SOURCE:http://goo.gl/VRhVo

If you App stores preference data in a location __OTHER THAN__ the standard location (.plist in ~/Library/Preferences), you will need a container migration

Labels: codesigning, gatekeeper, mac app store, sandbox

Red Sweater Blog – Developer ID Gotcha: "For the upcoming Gatekeeper feature in Mac OS X 10.8, Apple will make it easy for customers to prevent software from running that has not been digitally ‘signed’ by developers with a certificate from Apple called the Developer ID certificate.

A nice handy post about how the default designated requirements generated by the build process don't always behave as expected on various flavors of X.

Labels: codesigning, developerid, gatekeeper, sandbox, security

anchor apple generic and identifier "com.genkiyooka.developerID.mac.GK-DeveloperID" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = MQK467HD9A)

The code has been signed with following certificate chain:
NUMBER COMMON NAME
0 Developer ID Application: Gen Kiyooka
1 Developer ID Certification Authority
2 Apple Root CA


Labels: codesigning, developerid, gatekeeper, mac app store, receipt, security, validation

Gatekeeper Already Present in OS X 10.7.3, Available for Developer Testing [Archive] - MacRumors Forums: "By default, Gatekeeper is not enabled in Mac OS X v10.7.3. For testing purposes, you can turn it on by using the new Mac OS X system policy control command-line tool, spctl(8).Running the command 'sudo spctl' in Terminal will enable Gatekeeper on OS X 10.7.3."

A better description of enabling gatekeeper under 10.7.3 is here:
https://developer.apple.com/resources/developer-id/Developer-ID-Tutorial.pdf

In my testing under 10.7.3, the spctl commands did not work as described. But you can get it to work if you follow the macrumors post.

Labels: cocoa, gatekeeper, mac, sandbox

You may have heard about Developer ID and Gatekeeper, new security features coming in Mountain Lion. Essentially, this is an implementation of codesigning designed to secure 3rd party applications distributed over the internet.

Using Tighten Pro, you can inspect the certificate chain of any codesigned application. Last year, on stackoverflow.com, I wrote about the differences between the codesign on your app after you sign it with Xcode vs. your app after being delivered by the Mac App Store.

To summarize, the certificate chain looks like this after you sign it with Xcode and submit it to Apple for approval:

[LEAF] 3rd Party Mac Developer Application: "ME"
[AUTH] Apple Worldwide Developer Relations Certification Authority
[ROOT] Apple Root CA

After approval and delivery to the customer from the Mac App Store, the certificate chain looks like this:

[LEAF] Apple Mac OS Application Signing
[AUTH] Apple Worldwide Developer Relations Certification Authority
[ROOT] Apple Root CA

Under Gatekeeper and Developer ID, an application developed by you and shipped directly to customers after codesigning should look something like this:

[LEAF] Developer ID Application: "ME"
[AUTH] Developer ID Certification Authority
[ROOT] Apple Root CA

We've already tested Tighten with self-signed certificate chains and it works correctly as long as the leaf signing certificate has been signed by an intermediate authority (3 levels). It is possible to create your own Root CA and issue your own codesigning certificates. It can be done with Apple's Certificate Assistant (Keychain Access.app), but it is tricky due to bugs in Certificate Assistant.

Labels: codesigning, developerid, gatekeeper, mountain lion