Signing AutoPkg-built packages using a .sign recipe

For those that need to sign their AutoPkg-generated installer packages with a signing certificate, the PkgSigner processor is available to assist with this. When I originally started using this processor, I was building the signing part directly into .pkg recipes, but my teammate @jaharmi came up with a better and more modular idea: the .sign recipe.

The .sign recipe uses the PkgSigner processor and is designed to be placed in the AutoPkg workflow between a .pkg recipe and a.jss recipe for JSSImporter, a .munki recipe for Munki or other recipes used to upload an installer package to a deployment tool. In this case, the .pkg recipe would be a parent recipe for the .sign recipe. In turn, the .sign recipe would be used as the parent recipe for whatever came next in the workflow.

For those who want to use .sign recipes, there is an example recipe available via the link below:

https://github.com/autopkg/rtrouton-recipes/blob/master/SharedProcessors/Example.sign.recipe

If you want to use the PkgSigner processor hosted from my AutoPkg recipe repo, first verify that AutoPkg is installed on the Mac you’re using. Once verified, run the following command:

autopkg repo-add rtrouton-recipes

AutoPkg recipes for OS X Lion and OS X Mountain Lion OS installers now available

Now that Apple has made direct download links available for Lion and Mountain Lion, I’ve written AutoPkg .download and .pkg recipes for the following OS X installers:

• OS X Lion
• OS X Mountain Lion

These recipes will download the disk images linked to the relevant KBase articles, extract the installer packages stored inside the disk images and rename the disk images and installer packages with the OS name and version number.

One thing to be aware of is that the downloaded installers do not themselves install the relevant version of OS X. Instead, they install the Install.app for that version of OS X into the /Applications directory.

Another thing to know is that the downloaded installers are signed using Software Update signing certificates which expired in 2019. As of June 30th, 2021, I do not know if Apple is planning to re-sign the installers with the current Software Update signing certificate.

One of the consequences of this is that I cannot use AutoPkg’s code signature verification as part of the AutoPkg recipes, since AutoPkg’s current code signature verification will error when it hit the expired certificates. If Apple does choose to re-sign these certificate with valid non-expired signing certificates, I’ll add code signature verification to the recipes.

If you do need to use these installers, setting the system clock on your Mac to a date and time before the October 24th 2019 expiration date will allow these certificates to appear as valid again and any expiration-related issues should go away.

The AutoPkg recipes are available via the links below:

OS X Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXLion
OS X Mountain Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXMountainLion

Session videos from MacDevOps YVR 2021 now available

The MacDevOps YVR folks have posted the session videos for from MacDevOps YVR 2021, including the video for my Ride on the Release Train session.

For those interested, all of the the MacDevOps YVR 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.

Slides from the “Ride on the Release Train” session at MacDevOpsYVR 2021

For those who wanted a copy of my talk at the MacDevOpsYVR 2021 conference, here are links to the slides in PDF and Keynote format.

PDF – https://tinyurl.com/MDOYVR2021PDF

Keynote – https://tinyurl.com/MDOYVR2021Keynote

AutoPkg repo and logfile cleanup scripts for use with autopkg-conductor

As part of running autopkg-conductor over a long period of time, you may see a large percentage of disk space used on the Mac where you’re running AutoPkg and autopkg-conductor. This is because AutoPkg doesn’t remove older files from ~/Library/AutoPkg/Cache and autopkg-conductor does not remove older logfiles from ~/Library/Logs. To assist with this issue, I’ve written a couple of scripts. For more details, please see below the jump.

Using Signing Manager with autopkg-conductor

I’ve recently been working with Twocanoes Software’s Signing Manager in combination with my autopkg-conductor tool for managing AutoPkg runs. I’m happy to report it’s possible, but you may need to make some adjustments to how autopkg-conductor is being launched. For more details, please see below the jump.

Using the Jamf Pro API to mass-delete obsolete packages and scripts

If you’re using AutoPkg and tools like jamf-upload or JSSImporter to automate the uploading of packages and scripts to your Jamf Pro server, it may be necessary to periodically delete a large number of now-obsolete installer packages or scripts from your server. To help with this, I’ve written a couple of scripts to help automate the deletion process by using a list of Jamf IDs and the API to perform the following tasks:

1. Delete the relevant installer packages or scripts.
2. Generate a report of which packages or scripts were deleted.

For more details, please see below the jump.

Using Twocanoes’ Signing Manager to sign AutoPkg-built installer packages

As part of many application or package building workflows, there is a requirement to sign the end result to guarantee that the app or package has not been tampered with. With the advent of Apple’s notarization process, this has become even more important because an app or installer package must be signed before it can be notarized.

However, in order to sign apps or packages, you must have the signing certificate available. This has often meant putting copies of Apple signing certificates, complete with the certificate’s private key, onto the Mac or Macs used to build the application and/or installer package. This has security concerns because if the signing certificate’s private key is compromised, you must now revoke the existing certificate, get a new one from Apple and re-sign everything that used that now-revoked signing certificate.

To assist with the security concerns, Twocanoes Software has developed Signing Manager. This tool provides a way to centralize hosting of signing certificates and make their signing capabilities securely available to Macs which need them. In my own case, I’m investigating Signing Manager in the context of signing AutoPkg-built installer packages. For more details, please see below the jump.

Setting up AutoPkg, AutoPkgr and JSSImporter on an Amazon Web Services macOS EC2 instance

One of the outcomes of the recent Amazon Web Service’s Insight conference was AWS’s announcement that, as of November 30th, macOS EC2 instances were going to be available as on-demand instances or as part of one of AWS’s reduced cost plans for those who needed them long-term.

There are a few differences about AWS’s macOS offerings, as opposed to their Linux and Windows offerings. macOS EC2 instances are set up to run on actual Apple hardware, as opposed to being completely virtualized. This means that there are the following dependencies to be aware of:

1. macOS EC2 instances must run on dedicated hosts (AWS has stated these are Mac Minis)
2. One macOS EC2 instance can be provisioned per dedicated host.

AWS has also stipulated that that dedicated hosts for macOS EC2 instances have a minimum billing duration of 24 hours. That means that even if your dedicated host was only up and running for one hour, you will be billed as if it was running for 24 hours.

For now, only certain AWS regions have EC2 Mac instances available. As of December 20th, 2020, macOS EC2 instances are available in the following AWS Regions:

• US-East-1 (Northern Virginia)
• US-East-2 (Ohio)
• US-West-2 (Oregon)
• EU-West-1 (Ireland)
• AP-Southeast-1 (Singapore)

The macOS EC2 instances at this time support two versions of macOS:

• macOS Mojave
• macOS Catalina

macOS Big Sur is not yet supported as of December 20th, 2020, but AWS has stated that Big Sur support will be coming shortly.

By default, macOS EC2 instances will include the following pre-installed software:

• ENA drivers
• EC2 macOS Init
• EC2 System Monitoring for macOS
• Systems Manager SSM Agent for macOS
• AWS Command Line Interface (AWS CLI) version 2
• Xcode Command Line Tools
• Homebrew

For folks looking to build services or do continuous integration testing on macOS, it’s clear that AWS went to considerable lengths to have macOS EC2 instances be as fully-featured as their other EC2 offerings. Amazon has also either made it possible to install the tools you need or just went ahead and installed them for you. They’ve also included drivers for their faster networking options and made it possible to manage and monitor Mac EC2 instances using AWS’s tools just like their Linux and Windows EC2 instances.

That said, all of this comes with a price tag. Here’s how it works out (all figures expressed in US dollars):

mac1 Dedicated Hosts (on-demand pricing):

$1.083/hour (currently with a 24 hour minimum charge, after which billing is by the second.)
$25.99/day
$181.93/week
$9493.58/year

Now, you can sign up for an AWS Savings Plan and save some money by paying up-front for one year or three years. Paying for three years, all cash up front is the cheapest option currently available:

$0.764/hour
$18.33/day
$128.31/week
$6697.22/year

Now some folks are going to look at that and have a heart attack, while others are going to shrug because the money involved amounts to a rounding error on their existing AWS bill. I’m mainly going through this to point out that hosting Mac services on AWS is going to come with costs. None of AWS’s existing Mac offerings are part of AWS’s Free Tier.

OK, so we’ve discussed a lot of the background but let’s get to the point: How do you set up AutoPkg to run in the AWS cloud? For more details, please see below the jump.

PkgSigner AutoPkg processor updated for Python 3

A while back, I discussed how to incorporate installer package signing into AutoPkg workflows. The PkgSigner processor used in this workflow was originally written by Paul Suh and it uses Apple’s productsign tool to access a Developer ID Installer certificate stored in the login keychain.

Like other processors and AutoPkg itself, PkgSigner needed updating to Python 3 when Python 2 reached end-of-life in April 2020. This updating process has been completed, thanks to Nick McDonald. To make sure PkgSigner is consistently using the same Python environment across machines, PkgSigner has also been set to use the Python 3 install bundled with AutoPkg.

For those who need it, I have a copy of the PkgSigner processor available via the link below:

https://github.com/rtrouton/AutoPkg_Processors/tree/master/PkgSigner