Creating a sysdiagnose file using Activity Monitor

The sysdiagnose tool is used for gathering a large amount of diagnostic files and logging, and it’s often very useful when it comes to figuring out why a problem is happening. However, it can sometimes be challenging to get a sysdiagnose-generated file from someone who is not comfortable with using the Terminal as the usual method for generating a sysdiagnose file involves opening the Terminal and running commands there.

Fortunately, there’s also a way to generate a sysdiagnose file using Activity Monitor. This may be an alternate way to help get you the desired sysdiagnose file from someone who normally wouldn’t ever use the Terminal on macOS. For more details, please see below the jump.

Granting Volume Owner status on Apple Silicon Macs

macOS on Apple Silicon Macs includes a concept known as volume ownership. You must be a volume owner to perform the following tasks on an Apple Silicon Mac:

• Make changes to startup security policy for a specific install of macOS.*
• Be able to authorize the installation of macOS software updates or macOS upgrades.
• Authorize running Erase All Contents and Settings.

* There may be multiple installations of macOS on one Apple Silicon Mac; each macOS install would have their own startup security policy.

For more information on volume ownership, please see Apple’s Platform Deployment article linked below:

https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e/web (see the Volume ownership section.)

How do you get volume ownership though? It turns out that Apple has this currently set up on macOS as a two-fer deal: If an account account has Secure Token, it is also granted volume ownership. For more details, please see below the jump.

Setting a user account to automatically log in using sysadminctl on macOS Ventura

On macOS, it’s possible to set an account to automatically log in. However, up until macOS Ventura, there hasn’t been an Apple command line tool available which will do the following:

• Set the desired account to automatically log in
• Create the /etc/kcpassword file

Setting the desired account to log in could be accomplished by running the following command with root privileges:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser -string username_goes_here

view raw

gistfile1.txt

hosted with ❤ by GitHub

The hard part was correctly creating the /etc/kcpassword file, which stores an obfuscated copy of the password used by the account which is being set for auto-login. Without that file properly created and available in the specified location, the automatic login process would fail. For those interested in how the kcpassword file is set up, please see the link below:

https://www.offsec.com/offsec/in-the-hunt-for-the-auto-login-setup-process/

There have been several tools built by the community which successfully create the kcpassword file, but Apple themselves hadn’t provided a way to do this in macOS Monterey or earlier, outside of using the GUI for Users & Groups in System Preferences.

As of macOS Ventura, the sysadminctl command line tool has been updated with functionality to enable and disable auto-login for specified accounts. For more details, please see below the jump.

Backing up Der Flounder Revisited Once Again

Eleven years ago, I wrote a post on how I back up this blog. Overall, the reasons I’m backing up haven’t changed:

• I like this blog and don’t want to see it or its data disappear because of data loss
• WordPress.com’s free hosting doesn’t provide me with an automated backup method.

Two years ago, I wrote another post on how I needed to switch from hosting on a Mac to now hosting on a Raspberry Pi. The overall methodology hadn’t changed, I was creating a nightly mirror using HTTrack. This worked fine until the latest move to a new host in February 2023, where HTTrack was failing for me because the Raspberry Pi was running headless without a connected display and HTTrack was having problems with trying to launch a headless browser. After an hour of futzing with it, I moved to using wget. The wget tool has a number of handy options for mirroring websites, including the following:

• –mirror: Makes the download recursive, with recursive browsing and infinite recursion depth.
• –convert-links: Convert all the links to relative, so it will be suitable for offline viewing.
• –adjust-extension: Adds suitable filename extensions to filenames, (html, css, etc.) depending on their content-type.

Based on my research, using wget would be a decent replacement for what I had been doing with HTTrack and wouldn’t have the problems I was seeing with HTTrack not being able to launch a headless browser session. For those wanting to know more, please see below the jump.

Apple Device Management Second Edition book now available for purchase from Amazon, Apple Books and Apress

As covered previously, I worked with my colleague Charles Edge to update our Apple Device Management book with new information for a new second edition. I’m delighted to announce it’s now available for regular sale from Amazon, Apple Books and Apress, our publisher!

• Amazon: https://a.co/d/bnCAr5W
• Apple Books: https://books.apple.com/us/book/apple-device-management/id6445786866
• Apress: https://rd.springer.com/book/10.1007/978-1-4842-9156-6

Just like First Edition, Second Edition is a quality item stuffed with useful information. Also like First Edition, Second Edition is suitable for any gift-giving occasion in addition to being the perfect something for yourself. For those who have asked about it being available in electronic format, it’s available in the following formats depending on the seller:

• Amazon: Available for the Kindle
• Apple Books: Available in ePub format
• Apress: Available in PDF format

One thing to be aware of is that First Edition was also initially available via Apple Books, then later disappeared. I don’t know if that will happen with Second Edition, but if you want to get it for Apple Books my advice is to get it now and avoid disappointment and future regret.

Providing Jamf Pro computer inventory information via macOS configuration profile

Jamf Pro can store and make available a lot of information about a particular computer and who is using it as part of the computer’s inventory record, but it can be challenging to access that information from the computer itself.

It is possible to use an API call to access this information, using either the Jamf Pro API or Jamf Pro’s Classic API, but that means providing a way to authenticate to the API. This may pose some security issues as you will need to both:

• Provide a way for the computer to access those authentication credentials
• Protect the authentication credentials from potentially malicious third parties

Fortunately, there is an alternative way to provide at least some inventory information without needing to make an API call. Jamf Pro provides a number of variables which can be used in macOS configuration profiles and it’s possible to leverage those variables to build a profile whose task is providing information from the computer’s inventory record in Jamf Pro in a way which can be accessed from the managed computer. For more details, please see below the jump.

Certificate expiration affecting macOS App Store and VPP apps

Mac admins who have previously installed macOS apps from the Mac App Store (MAS) or the Volume Purchase Program (VPP) may be seeing some of those apps displaying warning messages on launch that the application is damaged.

When observed, this behavior may be appearing because the certificates Apple has been using to digitally sign apps have recently expired, on February 6th 2023 or February 7th 2023. (Both expiration dates have appeared in signing certificates on the apps I’ve checked.)

When the code signing is detected as being invalid, Apple’s security tools are blocking launch as a consequence. In most cases, it appears that the code signing is still appearing as valid despite being past the expiration date.

---

Update: February 13, 2023 – I’ve received feedback from @macmuleblog after posting that they have seen damaged apps from VPP where they had a valid code signing certificate, so the root cause for the damaged apps may be different than what I initially posted. My apologies for any confusion caused.

---

Both the Apple Mac OS Application Signing certificate used to sign the apps, and the Apple Worldwide Developer Relations Certification Authority intermediate certificate are showing expiration dates that are now in the past.

In the cases where I’ve experienced applications reporting as damaged, uninstalling the app and reinstalling it seems to have addressed the issue. Hopefully Apple is working on getting the issue handled by re-issuing apps which are signed with a certificate signed with a new expiration date in the future.

---

Update: February 13, 2023 – It looks like Apple had previously begun the code signing effort I requested above. When I checked Microsoft’s To Do app, I saw that the Apple Mac OS Application Signing certificate used to sign the app and the Apple Worldwide Developer Relations Certification Authority intermediate certificate are showing expiration dates in the future.

---

Using the Jamf Pro API to retrieve FileVault personal recovery keys

As part of Jamf Pro 10.43’s release, Jamf has added the ability to access and retrieve FileVault personal recovery keys via the Jamf Pro API:

• Return FileVault information for a specific computer: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-id-filevault
• Return paginated FileVault information for all computers: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-filevault

For those who want to use this new capability, I’ve written a script which uses the Jamf Pro Classic API and Jamf Pro API to take a list of Jamf Pro computer IDs from a plaintext file, retrieve the associated Macs’ FileVault personal recovery keys and generate a report in .tsv format.

For more details, please see below the jump.

Verifying installer package signing and notarization using pkgutil

Recently I needed a way to verify whether an installer package was signed and notarized. I’ve been using Apple’s stapler tool as my usual go-to for verifying notarization. However, the stapler tool needs for Xcode to to be installed and I needed a solution that worked regardless of Xcode or the Xcode Command Line Tools being installed on the Mac in question.

After some digging, I found that pkgutil‘s check-signature function on macOS Monterey and later works great for this and doesn’t have any dependencies on Xcode or the Xcode Command Line Tools. The pkgutil tool is installed as part of macOS and the check-signature function displays the following on Monterey and later:

If a package is not signed:

If a package is signed with a certificate:

If a package is signed with a certificate and trusted by Apple’s notarization service:

To use the check-signature function, you should be able to use the command shown below (substituting /path/to/installer.pkg with the actual directory path of the installer package you want to check.):

/usr/sbin/pkgutil –check-signature /path/to/installer.pkg

view raw

gistfile1.txt

hosted with ❤ by GitHub

Finding the version number of the Xcode command line tools using the softwareupdate command

As part of making sure your development environment is up to date, it’s often helpful to know what version of Xcode or the Xcode Command Line Tools that you’re using. For Xcode, this is relatively straightforward as you can check Xcode.app‘s version number or you can use the command shown below:

xcodebuild -version

view raw

gistfile1.txt

hosted with ❤ by GitHub

On a Mac running Xcode, running that command should provide output similar to what’s shown below:

	username@computername ~ % xcodebuild -version
	Xcode 14.2
	Build version 14C18
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, for the Xcode Command Line Tools, this process isn’t as straightforward. There isn’t a specific app to check for version information and running the command above results in the following output:

	username@computername ~ % xcodebuild -version
	xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

So how can you determine the latest installed version of the Xcode Command Line Tools? One way is to use the softwareupdate command’s history function, which should show all of the versions of the Xcode Command Line Tools which have been installed. You can use the following command to display all the installations of the Xcode Command Line Tools:

softwareupdate –history | grep "Command Line Tools for Xcode"

view raw

gistfile1.txt

hosted with ❤ by GitHub

For example, since both Xcode Command Line Tools 12 and Xcode Command Line Tools 13 are available for macOS Big Sur 11.7.x, you may see output similar to what’s shown below on a Mac running Big Sur:

	username@computername ~ % softwareupdate –history | grep "Command Line Tools for Xcode"
	Command Line Tools for Xcode 12.5 09/21/2022, 15:04:54
	Command Line Tools for Xcode 13.2 01/17/2023, 11:18:19
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

Since the latest installed version of the Xcode Command Line Tools should be listed at the bottom of the output from the softwareupdate command’s history function, you should be able to use the following command to get the version number of the latest installed version of the Xcode Command Line Tools:

softwareupdate –history | awk '/Command Line Tools for Xcode/ {print $6}' | tail -1

view raw

gistfile1.txt

hosted with ❤ by GitHub

As of the date of this post, the latest version of the Xcode Command Line Tools on macOS Ventura 13.1 is version 14.2, so you should see output similar to what’s shown below on a fully updated macOS 13.1 Mac running the latest version of the Xcode command line tools:

	username@computername ~ % softwareupdate –history | awk '/Command Line Tools for Xcode/ {print $6}' | tail -1
	14.2
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub