Background on the security method change
Outset is a tool for Mac admins that allows you to have various scripts run at boot, at login, or on demand.
Originally, Outset would run any scripts in its folders, as long as the scripts had the proper permissions and ownership.
Eventually, Outset supported using a sha256 hash of each script to have an MDM profile validate that scripts are approved to be run. This would invalidate a malicious actor’s modifying an existing script or dumping a new script into one of your Outset folders (any malicious person or process being able to modify root-owned folders would be a cause for concern already, but this validation process was an extra safeguard).
Starting with Outset 4.3.0, the sha256 hash validation process is deprecated but—at least for 4.3.0 (maybe not in future versions)—is still functional, which will allow you to transition from sha256 hash validation to script signing while using the same version of Outset.
Script signing makes it so you don’t have to re-deploy a new version of the MDM profile every single time you change the contents of a script or deploy a new script. You can have the same MDM profile and just sign or re-sign the script.
Transitioning
The wiki already tells you how, from a technical standpoint, you can do the migration: github.com/macadmins/outset/wiki/ScriptSigning#migration-from-sha256-checksums
But what if you want to make that transition gradual? For example, maybe you want to roll out the signed scripts in stages to be able to verify everything is functioning as expected, instead of just flipping it all for your entire fleet (which could be thousands or tens of thousands of Macs).
First of all, I’ll say that you can’t meaningfully have both manifest_signing_key and sha256sum keys deployed in your Outset MDM profile. Once you put in manifest_signing_key, Outset will essentially look only for script signing and ignore any hash checks in sha256sum.
So if you try to have both keys in the same profile, you essentially have only one functional one (manifest_signing_key), and so your unsigned script that has a hash in the profile just won’t run:
<key>manifest_signing_key</key>
<string>+dfi8lLWqzEkk3FBjkcz+j1qlZId+Y/ZmR2Xh/M2jx0=</string>
<key>sha256sum</key>
<dict>
<key>/usr/local/outset/login-every/cool_outset_script.sh</key>
<string>e64d6502c690b02a7bde4eb02fa79d5cb9675464cdc4a84cc0e136386fe71d34</string>
</dict>
Instead, you’ll see something like this in the logs:
2026-09-13 13:15:33 INFO: Processing scheduled runs for login
2026-09-13 13:15:33 ERROR: Script signing: no embedded signature found in /usr/local/outset/login-every/cool_outset_script.sh
2026-09-13 13:15:33 ERROR: Skipping /usr/local/outset/login-every/cool_outset_script.sh: signature verification failed or signature absent
So what I’d recommend is to use whatever groups you have defined (Munki catalogs, Okta groups, smart groups, assignment groups, etc.), and have two separate profiles—your old Outset MDM profile with sha256sum
<key>sha256sum</key>
<dict>
<key>/usr/local/outset/login-every/cool_outset_script.sh</key>
<string>e64d6502c690b02a7bde4eb02fa79d5cb9675464cdc4a84cc0e136386fe71d34</string>
</dict>
and your new Outset MDM profile with manifest_signing_key
<key>manifest_signing_key</key>
<string>+dfi8lLWqzEkk3FBjkcz+j1qlZId+Y/ZmR2Xh/M2jx0=</string>
You’d sign all your old scripts and repackage them and redistribute them in groups or stages that correspond with your switch from the old MDM profile to the new MDM profile.
Let’s say your groups are something like development, testing, production.
You could do something like
- development – new scripts, new profile
- testing – old scripts, old profile
- production – old scripts, old profile
then
- development – new scripts, new profile
- testing – new scripts, new profile
- production – old scripts, old profile
and finally
- development – new scripts, new profile
- testing – new scripts, new profile
- production – new scripts, new profile
That’s an example of three groups, but if you have more, obviously use whatever groups or shards you have.
While signing, repackaging, and redistributing all your scripts now may seem like a lot of work, it should, in theory, save you work in the long term, as any future modifications to scripts would involve only re-signing them and redistributing them, and not also having to update and redistribute the MDM profile as well each time.
Leave a Reply