Manipulating the System Policy Database with Configuration Profiles, Part 2

You’re going to want to read Part 1 of this piece first. It covered managing the installation of packages that are not notarized. This section of the article covers the operational limits of doing the same thing for applications, using the operation:execute verb. There are several caveats to all of this that may make this procedure non-viable. But, there’s also a way to make it work, so here we are.

The Mechanism

Last time, we got a package installer whitelisted. That’s a simple operation: whitelist the certificate of the installer with the right Requirements payload, and the installer package will pass through quarantine checks unobstructed.

But what about a non-notarized application?

There are some software manufacturers who have challenging installers (which is to say: non-pkg, app-based installers) that require a different sort of whitelisting. In this example, we’re going to be reviewing the Cisco Webex Add-in. The installer is an application, intended to be run by a user. It’s a signed application, thankfully, and that gives us everything we need to build a whitelist to recover from the lack of a notarization process.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadDescription</key>
            <string>Configures Gatekeeper to accept developer certificate</string>
            <key>PayloadDisplayName</key>
            <string>System Policy Rule</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.systempolicy.rule.5B8D7EE6-199A-48BC-B317-F223FB036552</string>
            <key>PayloadType</key>
            <string>com.apple.systempolicy.rule</string>
            <key>PayloadUUID</key>
            <string>5B8D7EE6-199A-48BC-B317-F223FB036552</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>Requirement</key>
            <string>anchor apple generic and 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] = DE8Y96K9QP</string>
            <key>OperationType</key>
            <string>operation:execute</string>
            <key>Priority</key>
            <real>100.0</real>
            <key>Comment</key>
            <string>Test configuration 5 - OperationType: operation:execute</string>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Gatekeeper Config</string>
    <key>PayloadIdentifier</key>
    <string>com.example.156ED537-CB5E-4AC9-80D6-376234F2DF60</string>
    <key>PayloadOrganization</key>
    <string>Example</string>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>156ED537-CB5E-4AC9-80D6-376234F2DF60</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

The Requirement payload in this this profile might look familiar. The identifier and certificate language looks a lot like the Privacy Preferences Policy Control payload that was introduced with macOS 10.14 Mojave. Much as you would with with one of those payloads, deriving the contents is as simple as interrogating the application with codesign:

codesign -dr - /path/to/Application.app

This will return what you need to embed:

identifier "com.cisco.webex.Cisco-WebEx-Add-On" and anchor apple generic and 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] = DE8Y96K9QP

Once again, this is adding entries to the /var/db/SystemPolicy database, which Gatekeeper uses at inspection time to determine whether or not something passes. This is your pass past the security desk.

There Are Big Caveats

Okay, here’s where it gets less ideal.

There is only one road to a successful deployment.

This profile cannot be installed before macOS 10.15 Catalina is installed. Not because the profile can’t be interpreted by Mojave – it can – but because the installation process for macOS 10.15 might reset the SystemPolicy database.

And, because profiles are only ever interpreted at the time of install, you now have a profile that is installed on the machine, but no longer in the database that Gatekeeper uses.

One such failed case is here.

Once the profile’s installed, it’s installed, and it can’t or won’t be reinterpreted by the System. This is a huge flaw in the configuration profiles system overall, and we’ve seen it come back to bite us in the behind each of the last two revisions of the OS, with no revision in the system. The lack of defined-state management with configuration profiles, coupled with management-via-UDP profile delivery, means that we’re kinda stuck.

So, let’s talk about how this can go poorly.

Some MDMs have a method for reinstalling certain types of profiles after an operating system upgrade to make sure that profiles get reinterpreted, but none of those mechanisms are foolproof. There’s almost always a little lag between those mechanisms hitting and the upgrade completing.

What happens then?

Well, if the application is launched, and it won’t pass the Quarantine check, then the file gets marked as a failed application, and that file is, for all intents and purposes, blackballed.

Normally, that would mean the only recourse at that time is to uninstall and reinstall the application. If you have a good uninstall script, this could be a solution. There are some applications that aren’t such good citizens about containerization and slop their resources all over your filesystem.

But here’s the rub, even if you do catch all the resources, now you’re in an exorcism situation. There are some applications that just won’t be bypassed this way. I was able to get this working, but a colleague with another MDM has not been successful as of press time in making this work 100% of the time.

Well, That’s Bad. Now What?

Well, for starters, if you can, deploy these tools with other means. Remember that passing these checks are a lot like getting pass the security desk. Tools like the Jamf binary and root agents like Munki can build an Employees Entrance for key personnel. Installing with these tools bypasses the Quarantine process, which means notarization checks won’t apply.

If you’re expecting for users to directly download and manually install software that isn’t signed and notarized, you’re going to need to either have a robust help desk that can handle the volume, you’ll need to put pressure on your software vendor to do the responsible thing and fix their installer or fix their deployment mechanism(1).

Whitelisting is going to be a game of whackamole. If you have to play it, you’re going to need to plan for two things:

  1. Deliver your profiles with an MDM that can rapidly re-deliver the necessary profiles after a major version upgrade.
  2. Consider delivering your major version upgrade along-side a pre-install script that scrubs out packages that aren’t properly notarized.

Whatever you do, this is a use-case you will need to prepare your service desk for.

1.

Manipulating the System Policy Database with Configuration Profiles

First up, this post is a direct response to my previous posts on this summer’s talk about notarization. Notarization is a subject of much discussion, and there’s a lot happening out there. If you are looking for an exhaustive summary of notarization through many, many links, might I recommend this compilation post on Mr. Macintosh. If you are looking for the TL;DR, here it is: macOS 10.15 requires that software be notarized to pass the Gatekeeper checks. If it is not notarized, it will not pass these checks unless you can manipulate the System Policy Database to whitelist a Team’s certificate.

I didn’t do this alone, and I want to say a huge, huge thank you to everyone who helped me out as we tinkered through this somewhat opaque process.

In the Beginning, there was Gatekeeper and spctl

Before we go digging into how all of this works, you need to understand the importance of Gatekeeper in the process of reviewing the notarization of individual items. The spctl binary that is part of macOS’s command line interface, and has been for a very long time, are responsible for controlling what Gatekeeper looks at. These both write to a sqlite3 database stored at /var/db/SystemPolicy, and think of it a lot like a database of ID cards that the security guard at the desk will review. If your card is recognized, you pass through security without more than a passing hello at the barrier. If you card is not recognized, your ID is checked, your destination cleared, your name jotted down, and you’re granted a card if you belong.

This is how spctl whitelists applications for LaunchServices’ purposes.

This system can be directly manipulated via configuration profile, and those configuration profiles can be delivered by a capable MDM. Moreover, this has been the case since macOS 10.12. Hidden away in Apple’s documentation is the SystemPolicyRule payload type, which can allow you to embed whitelisted objects in an MDM Profile.

Anatomy of a SystemPolicyRule Payload

Properties of the SystemPolicyRule Payload
The key properties of the SystemPolicyRule payload

There are four interesting elements of the payload, and I’m going to take them in reverse order, from the bottom up:

Requirement is the policy requirement for the Code Signing information, and must match the syntax described by the CSRL. If you are familiar with writing PPPC policies in various tools, this will not be unfamiliar. The Requirement for our example profile is:

<key>Requirement</key>
<string>certificate leaf = $HASHCERT_DeveloperCertificate$</string>

In this case, the value of the string contains a reference to the hash of a specific certificate, here called DeveloperCertificate. We’ll come back to that certificate in a bit, but it corresponds to the signing certificate used by the developer to sign the package. Here, the $HASHCERT_ prefix is really a command to the MDM. It will derive a SHA hash value of the attached certificate and replace it in the string, so that the final value is then interpreted as:

certificate leaf = H"ca9284955c38aa337610c78e2bc1e532ef82ca2d"

Priority is the weighted value of the policy requirement for the payload. Rules can have varying priority level, and in our test profile, we’re using a Float value of 100.0.

Operation Type will tell you what kind of action you want govern. The operation type we care about for this example profile is an install. We want Gatekeeper to skip the notarization check during installation, so we’re going to add an OperationType of "operation:install"

LeafCertificate is the sticky point and that’s why I left it for last. You have to define the LeafCertificate of the signer. In our example profile that follows, the entirety of the public key of the signer’s certificate is embedded in the profile. This is going to require the most legwork, but there are shortcuts to get there. Flat packages in macOS have an XML Table of Contents, and you can use the xar command to extract it to a file where you can read it:

xar -t -f /path/to/your/package.pkg --dump-toc=toc.xml

You can now read the toc.xml file in BBEdit or any other fine text editors to review the contents of the XML table of contents, which will contain the signing certificate required for what follows:

XML File with X509 Certificate XML

This leads us to the sample profile.

Sample Profile

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadDescription</key>
            <string>Configures Gatekeeper to accept developer certificate</string>
            <key>PayloadDisplayName</key>
            <string>System Policy Rule</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.systempolicy.rule.1496C06B-32CC-4725-9648-D310B45D78AB</string>
            <key>PayloadType</key>
            <string>com.apple.systempolicy.rule</string>
            <key>PayloadUUID</key>
            <string>1496C06B-32CC-4725-9648-D310B45D78AB</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>DeveloperCertificate</key>
            <data>MIIFcTCCBFmgAwIBAgIIBS/BS5wUWZUwDQYJKoZIhvcNAQELBQAweTEtMCsGA1UEAwwkRGV2ZWxvcGVyIElEIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQLDB1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTETMBEGA1UECgwKQXBwbGUgSW5jLjELMAkGA1UEBhMCVVMwHhcNMTcwNjI5MTE1MDM1WhcNMjIwNjMwMTE1MDM1WjCBkTEaMBgGCgmSJomT8ixkAQEMCjQ2SlE2NTM1ODgxOjA4BgNVBAMMMURldmVsb3BlciBJRCBJbnN0YWxsZXI6IERleXNvbiwgSW5jLiAoNDZKUTY1MzU4OCkxEzARBgNVBAsMCjQ2SlE2NTM1ODgxFTATBgNVBAoMDERleXNvbiwgSW5jLjELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJl9BeLVXpspNA+ZQV8PcJ1zs0m3UZ9kW0PWGoHIL7qF1ngNnrd4+Lj62+DgasoVhZumWEL+GooYOZDQiswdAkF1qG7EPKXYmO6sfLNSKhVruha80LS/PpegqDJNsOw+o2ns3tNj7TTZ5BpSuyQlkiAO4mo92v+Qfhvqu1vmQHJi4nVF1wIxg+LFchkQJIElReb6+g1Y0xOIbxC3JM+wIMfDDKd1sz22zhP6i/t+EGDWoEnTyOV1dmCNgQloQcgetJmODJCEsj9h1sa4+FpQmbHdYxSQIHwnIfYOPQjoc4FPl7Da8dW5XSuTvLIzzfIn5rdmARwk6mq+rXSCM2AvfhAgMBAAGjggHiMIIB3jA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmFwcGxlLmNvbS9vY3NwLWRldmlkMDIwHQYDVR0OBBYEFP8Ryi3QibMrmNCHi5WAEtFQW6LWMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUVxftos/cfJihEOD8voctLPLjF1QwggEOBgNVHSAEggEFMIIBATCB/gYJKoZIhvdjZAUBMIHwMCgGCCsGAQUFBwIBFhxodHRwOi8vd3d3LmFwcGxlLmNvbS9hcHBsZWNhMIHDBggrBgEFBQcCAjCBtgyBs1JlbGlhbmNlIG9uIHRoaXMgY2VydGlmaWNhdGUgYnkgYW55IHBhcnR5IGFzc3VtZXMgYWNjZXB0YW5jZSBvZiB0aGUgdGhlbiBhcHBsaWNhYmxlIHN0YW5kYXJkIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHVzZSwgY2VydGlmaWNhdGUgcG9saWN5IGFuZCBjZXJ0aWZpY2F0aW9uIHByYWN0aWNlIHN0YXRlbWVudHMuMA4GA1UdDwEB/wQEAwIHgDAXBgNVHSUBAf8EDTALBgkqhkiG92NkBA0wEwYKKoZIhvdjZAYBDgEB/wQCBQAwDQYJKoZIhvcNAQELBQADggEBABoQkblcJ67ogJCItUxk/TyScFgx5Ln3PJt1OwOTy4GqriL2T+bI+bxd206pcIjN0T7DMfvHLv0vsUQuENo5uPFHQGQeTo1WLd6Ys99MkjhqbLpVJLVch/AVRExXzFLkpnTWAk0l4ApVScSIRUswUeONhRY7Mc+7dFPoX2oOtsjwIR/98QnCykwBd01c4dhgg10BQ4bHAZjmHj8kXiI+yEJAT9YcuEw4PfSN6BgDViZVdsRLZD8z2UViyzYnwtbbKvCE2dx302SJ/ka+AVbnZdH8ZLAb09rgO+U6fdvDidiWtLf2Itehf21w0pnU9bRIe/IgqGFFJehhLDTP/O5+vmc=</data>
            <key>Requirement</key>
            <string>certificate leaf = $HASHCERT_DeveloperCertificate$</string>
            <key>OperationType</key>
            <string>operation:install</string>
            <key>Priority</key>
            <real>100.0</real>
            <key>Comment</key>
            <string>Test configuration 3 - OperationType: operation:install</string>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Gatekeeper Config</string>
    <key>PayloadIdentifier</key>
    <string>com.example.934CF679-5ABA-444C-BCE1-22BA582182AD</string>
    <key>PayloadOrganization</key>
    <string>Example</string>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>934CF679-5ABA-444C-BCE1-22BA582182AD</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

I’ve tested this profile with SimpleMDM and a current macOS 10.15 Catalina system with a signed-but-not-notarized package that would fail to install otherwise, and I was no longer warned while trying to install this otherwise-quarantined package.

The profile was delivered via MDM and now shows a System Policy Rule with detail that matches our payload content. Now, keep in mind, the /var/db/SystemPolicy database only cares about the Requirement item, which is just a hex hash of the certificate. You can, if you choose, just include the hex hash in the Requirement item, but if you choose to do that, you will have to know what that hash represents. If you want to be kind to your users, which you should, you should include the Certificate itself, which will be decoded in the display to show you which signer and which certificate authority the certificate resolves against.

After the certificate is installed, you can check your work with a review of the /var/db/SystemPolicy sqlite3 database’s authority table. It should show a new entry that matched the newly whitelisted certificate:

The red box shows the newly added rule that arrived via MDM Profile.

This appears to be how you can whitelist individual signing certificates for notarization checks and distribute that whitelist to clients with a Mobile Device Manager using a payload that’s been around since macOS 10.12.

How Do I Do This For My Environment?

Start with a package that is signed, but not notarized. Using the xar command, extract the X509 Certificate of the package. You will need this for your profile.

Second, use uuidgen to create new UUIDs for the profile. You’ll need at least two. Replace the two UUIDs in your copy of the profile. UUIDs are paired in the PayloadIdentifier and PayloadUUID fields.

Customize your PayloadIdentifier and Comment fields with your organization and a description of the policy.

Postscript: Using This To Run Non-Notarized Applications

While all of the above is intended for the operation:install key, operation: execute would allow you to run non-notarized Applications without Gatekeeper dialogs for those applications that are downloaded in their entirety without an installer package. You will need a separate profile if you want to whitelist both an installer and an application.

Apple Updates Notarization Requirements

Notarization is a big topic amongst Mac Admins, as we start to prepare to release macOS 10.15 Catalina to our fleets. Distributing tools, and allowing users to setup their own environments, is a huge part of the Mac Admin life. Today, Apple released some new guidance concerning the requirements for notarization of software packages.

To make this transition easier and to protect users on macOS Catalina who continue to use older versions of software, we’ve adjusted the notarization prerequisites until January 2020.


You can now notarize Mac software that:
• Doesn’t have the Hardened Runtime capability enabled.
• Has components not signed with your Developer ID.
• Doesn’t include a secure timestamp with your code-signing signature.
• Was built with an older SDK.
• Includes the com.apple.security.get-task-allow entitlement with the value set to any variation of true.


Make sure to submit all versions of your software. While Xcode 10 or later is still required to submit, you don’t need to rebuild or re-sign your software before submission.

Apple Developer News

This represents a substantial change over the existing guidelines. This is a positive development, in my eyes, which allows more developers to submit their packages, disk images and zip files for notarization in their current form, and to work over a longer term to get the Hardened Runtime enabled, as well as find replacements for third-party pre-compiled frameworks that are submitted with another developer’s signature embedded.

This does still mean you need to get notarized packages, zips and disk images for your environment if you intend to have 3rd party non-AppStorer software installed directly by end users. If you are installing tools via Munki’s LaunchDaemons or Jamf’s framework, this doesn’t apply yet.

Like the Return of an Old Friend: NetNewsWire 5.0

In the early days of Web 2.0, in the short time after the dot com crash, there arose a common standard for syndicating your blog across the web, into RSS Readers. Google Reader was a big damn deal in those days, but before Google Reader hit the market, there was NetNewsWire.

Brent Simmons’ app was the RSS Reader for the Mac for a good long time, and an app that I lived and died by. In the days where Twitter (blessedly) did not yet exist, getting your news meant going to a website manually, like some kind of animal. NetNewsWire could read the secret code that held these sites together and produce a feed of articles that you could pay attention to directly, without having to remember which sites you needed to see.

In the post-social world, where suddenly everything got dumped out to the feeds full of our friends’ quick thoughts and longer form rants, RSS began to die a bit. Google saw that Reader was cannibalizing their own ads, and rapidly pushed it to the ash-heap of history, and in-so-doing, wrecked a whole lot of models for publishing. Suddenly, we were back to depending on people to go to browser-based reading habits, which came with a ton of terrible ads, tracking that was just full of garbage, or a social existence defined by the hellscape that Twitter and Facebook have become.

All this set the table for the return of NetNewsWire, which exited beta last week, and returned to my dock shortly thereafter. The base metaphor of NetNewsWire (NNW) is unchanged: feeds, grouped according to your choices, contain stories, which can view feed by feed, or in a timeline. Anything that can be served up as RSS can be shunted over into NNW’s hopper to await your attention.

For the last few years, I have used the #blog-feed channel on the Mac Admins Slack as my version of a professional RSS reader. I’m moving all those feeds to NetNewsWire so I can better track what I’ve read and what I haven’t. Now I’ve got a great view into what I’m up to date on, and what I’m yet to cover.

A view into my RSS feeds

This is about to be heavy season for Mac Admins, if it’s not already. We’re in the waning days of the beta period before macOS Catalina 10.15 drops and iOS 13 is released. We’ve got a lot of work ahead of us. How about helping yourself with a whole list of helpful feeds that are there to keep you up to date?

Enter the Mac Admin Blogs OPML Repo.

Download the OPML File, Open NetNewsWire, File > Import Subscriptions.

And there ya go!

The repo is public on Github, so feel free to contribute those blogs I missed.

And congratulations, Brent Simmons! NNW 5.0 is a return to RSS for me, and I couldn’t be more excited to be reading more from my friends.

Notarization Follow-Up and Video

The Loyal Order of the Notaries

This summer, I gave a talk at the Mac Admins Conference at Penn State, focused on Notarization, called The Loyal Order of Notaries. It was a lot of work to put together the talk, and I spent more time on it than I have any talk I’ve ever given. I am proud of the work, but there’s a problem.

I Got Something Very Wrong

46 minutes into the talk I said: “this is good news: whitelisting the Team ID affects the notarization restriction.”

This is not correct.

Whitelisting the Team ID in a Kernel Extensions payload from a User-Accepted MDM does not affect the notarization requirements in the Catalina betas at this time. What I said in the talk was based on my conversations with colleagues and friends, and an conversation I’d had with a member of Apple’s staff, and on my initial results with the first beta of Catalina.

My conclusions were based on the question I asked in that inteview: Will there be a way to whitelist Developer IDs for notarization the same way there is for Kernel Extension loading? The answer was an unequivocal yes.

I assumed that the method for this was the same payload. That has turned out not to be the case in my testing thus far.

So What Now?

I don’t know.

That’s not a very satisfying answer, I recognize. I wish I had a better one.

Here’s what I do know: merely providing a kernel extensions whitelisting of the Team ID of a Developer is insufficient to prevent warnings for packages and disk images signed with that Developer Certificate.

I feel like I blew it.

I had tested this with my Catalina machine, but I realized that the package I was testing with was signed, and with a Developer ID I’d whitelisted, but it wasn’t a unique path or package. I had already installed that package once before, before I’d whitelisted the Developer ID. The LaunchServices Database had a record of the package and the path from where it had come from. It had already exited quarantine, and thus wasn’t passing through the Gatekeeper checks that the talk described, despite having been uninstalled.

How Do I Deal With Non-Notarized Materials?

Catalina’s requirements for notarization on signed packages, signed disk images and unsigned zip files are enforced by Gatekeeper processes, which depend on file quarantine flags. If a package, disk image or zip file arrives via browser download, USB file transfer, or AirDrop transaction, it comes with a quarantine flag. Escaping quarantine means passing a notarization check (online or offline), and a code-signing check, and a check for malicious code as defined by MRT and XProtect.

Or, you can deliver the payload through a non-quarantine method, like curl, or the jamf binary.

These methods are not quarantine aware, and while they do carry some additional ACLs, they do not appear to prevent the installation of packages by Apple-signed Installer, or mount of the image by Apple-signed Disk Utility. That means that tools like Munki or Jamf can continue to deploy software that is not notarized to enterprise machines.

One other consequence of these changes is that it’s not just packages software programs that are affected. During testing, I found a package that is properly signed that delivers Motion and Final Cut Pro templates that also triggered the quarantine warning. They were signed for distribution, but not notarized. They still flagged the quarantine check because they were distributing files. I packaged a sent of fonts for delivery to /Library/Fonts, signed the package, uploaded it to Slack for a colleague to test, and sure enough, quarantined:

If you’re planning for your co-workers to be able to open packages, zip files or disk images that aren’t notarized, you’re going to need to prepare them to right-click on the file, click Open, and then accept the warning that follows.

This isn’t ideal.

This will mean that anything you intend to deliver to Catalina computers will need to either arrive without a Quarantine flag, or be installed by a tool that can receive updates without a Quarantine flag and install them directly.

I apologize to the folks in the room at Penn State, to the organizers of the Mac Admins conference, and to anybody who will see the video. I got it wrong. But I’ll own what’s mine, and we’ll learn more together in the future.

Go For The Moon

Last night, we braved the crowds and the heat to go down to watch Go For The Moon, a multimedia spectacular in front of the Smithsonian Castle. The experience was like nothing I’ve ever seen, or could imagine. Using the Washington Monument as a canvas, along with a pair of split screens framing the obelisk, the incredible team at the National Air & Space Museum and 59 Productions made magic.

Projecting a life-sized Saturn V rocket launch on the Washington Monument, and eventually the arrival of Eagle on the Moon, along with the Rice University speech and the achievement of the Apollo programs, the audience is left to sit in awe for 17 minutes as the video plays out. The score, by Jeff Beal, provides additional encouragement.

The Rice University speech, famous for it’s “We choose to go to the Moon… because it will be hard” also has an incredible section on ethical leadership in technological pursuits:

“For space science, like nuclear science and all technology, has no conscience of its own. Whether it will become a force for good or ill depends on man, and only if the United States occupies a position of pre-eminence can we help decide whether this new ocean will be a sea of peace or a new terrifying theater of war. I do not say the we should or will go unprotected against the hostile misuse of space any more than we go unprotected against the hostile use of land or sea, but I do say that space can be explored and mastered without feeding the fires of war, without repeating the mistakes that man has made in extending his writ around this globe of ours.”

Pres. John F. Kennedy, Rice University, September 12, 1962.

President Kennedy said what so many miss: the application of science and technology has no direct conscience of its own, but rather it is the product of people, in their designs, intents, applications, choices, audiences, marketing, and execution of it. The parallels between the strife of the 1960s and the 2010s was clear last night down on the Mall. We were reminded that Apollo happened amid the unjust Vietnam War, amid the unjust fight against the Civil Rights Act, amid the countercultural rebellion against post-war norms.

“We came in peace for all mankind,” reads the plaque on the leg of Eagle, where it remains today. We are capable of doing incredible things as a nation, and NASA is the embodiment of those goals of exploration, of science, of application of technology. It’s just a part of the funding of science that we do as a nation, as part of our pursuit of the future. We need to do more science, not less. We need to do more exploring, not less.

We need the next velcro, the next teflon, the next LED bulb, the next micro computer, and programs like NASA’s Apollo can build those things, in concert with the National Science Foundation. We can do incredible things when we make science and technology into public goods. Engineering and exploration in the pursuit of the furtherance of humanity is a worthy goal for us all.

And we need it now, more than ever.

We took Charlie with us, last night, to see the rocket go up. We’ve been watching From The Earth To The Moon this week, and I know while he was with my parents they talked a lot about the original moon landing in 1969. Like his father, and his grandfather, he thrust his fist in the air as the rocket went up.

I’m sure there are those who see the rocket programs and exploration of space as secondary or tertiary to the other problems of our present. I can understand that. But what will save our planet in the next century is science. It’s certainly not sticking our head in the sand and hoping for divine intervention that isn’t coming. We have to participate in our own rescue. As we bake in record heat — more of a braise, here in DC this weekend — it’s more and more clear that our climate is changing, and with it our future habitability. Kim Stanley Robinson’s science fiction novels of the last decade are fairly bleak and fairly clear: if we’re getting through this, we’re doing it here, not living anywhere else. I think he’s got a point.

If there’s an Apollo program for Charlie’s generation, it may not be about Mars, or the Moon, or Titan or Enceladus. It might be here. But we have to keep going, keep pressing the boundaries of human space, pressing what we’re capable of.

In 50 years, I plan to be back out on the Mall with him for Apollo 100, helping him remember what came before, and what we have yet to accomplish.

Slide from talk, titled The Loyal Order of Notaries

Mac Admins Talk: The Loyal Order of Notaries

The Notarization of binaries with Apple Notary Service is a fascinating topic worth exploring, and in this year’s talk at Mac Admins, I delved deep into the subject. The current version of macOS now requires all kernel extensions not just to be signed by their authors, but to be notarized by the Apple Notary Service. Beginning with macOS 10.15 Catalina, all software will need to be notarized, as well.

This represents a bit of a change over the past, and it will require software developers not just to submit their software for notarization, but to staple the resultant ticket to their binary. Doing this isn’t terribly complicated, but why does this have to happen? What’s the mechanism for getting something notarized? How can we work around this, if circumstances require it?

This post is designed to be both the repository for the slides from this talk, as well as useful links and documentation associated with the materials discussed in the talk. I will not be including my presenters notes.

Follow-Up

Please read this important follow-up before reading the resources that follow.

Slides & Downloads

Here are the slides associated with the talk.

Download (PDF)

Online Resources

Apple: Safely open apps on your Mac, a Gatekeeper Guide
Apple: Your Apps and the Future of macOS Security, a WWDC Video from 2018
Apple: Advances in macOS Security, a WWDC Video from 2019
Howard Oakley: Notarization Category on Eclectic Light, a collection of blog posts on notarization
Apple, Gatekeeper and Developer ID, a WWDC transcript from 2012
Rich Trouton: Clearing the quarantine extended attribute, a blog post on xattr and quarantine bits.
Howard Oakley: More about the quarantine extended attribute, a blog post on xattr and quarantine bits.
Mothers Ruin: Suspicious Package, a tool for reviewing packages and apps

Thank Yous

My sincerest thanks to #notarization on the Mac Admins Slack, to people like Joel Rennich, Robert Hammen, Rich Trouton, Armin Briegel, Jennifer Unger, Dr. Emily Kausalik-Whittle, Some Little Birdies, and anyone else I inflicted my questions and draft slides on. I also want to thank Apple for their wealth of new documentation tools, and the WWDC video archives.