I'm seeing a problem with custom Installer plugins on macOS 27 beta 5 and beta 6. I have a .pkg containing a custom Installer plugin. The plugin is properly signed, and if I check it manually from Terminal, codesign is happy with it and doesn't report any errors. However, when I install the package by double-clicking the .pkg in Finder, the plugin is not loaded. I see this in the logs: amfid: /private/tmp/com.apple.installer.../KLNagentInstallPlugin.bundle/Contents/MacOS/KLNagentInstallPlugin not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" So apparently the plugin fails signature validation after Installer extracts it into /private/tmp, even though the same plugin passes codesign validation. This package/plugin worked on earlier macOS versions. So far, I've reproduced the issue on macOS 27 beta 5 and beta 6. Has anyone else run into this? Did anything change in macOS 27 regarding signing or validation of custom Installer plugins? I've also filed this via Feedback Assistant - FB24415432.
Custom Installer plugin fails signature validation on macOS 27 beta 5/6
This package/plugin worked on earlier macOS versions.
Earlier versions of macOS 27 beta?
That is, did this break in 27.0b5? Or is in broken in all versions macOS 27 beta?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Earlier versions of macOS 27 beta?
Yes, all work fine on earlier versions of macOS 27 - beta 4 and below (including macOS 26). Things started to go wrong on 27.0b5.
During a more detailed investigation of the issue, I’ve found that code signature verification fails with an ELOOP (62) error:
amfid: (Security) [com.apple.securityd:security_exception] UNIX error exception: 62
I also tried to verify the code signature of the target plugin bundle after it had been copied by the installer into its temporary directory:
codesign -vvv /private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle
This produces the same error:
/private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle: Too many levels of symbolic links
Further investigation showed that most of the contents of the plugin bundle's Contents directory are symbolic links to another temporary directory, with the exception of the MacOS directory:
ls -l /private/tmp/com.apple.installerXBGBPjSU/KLNagentInstallPlugin.bundle/Contents
total 0
lrwxr-xr-x 1 test wheel 128 26 Aug 11:24 _CodeSignature -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/_CodeSignature
lrwxr-xr-x 1 test wheel 124 26 Aug 11:24 Info.plist -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/Info.plist
drwxr-xr-x 3 test wheel 96 26 Aug 11:24 MacOS
lrwxr-xr-x 1 test wheel 123 26 Aug 11:24 Resources -> /var/folders/7v/rk69xf7d6f7f14rdtl823b0r0000gn/T/com.apple.install.a5sSNybs/KLNagentInstallPlugin.bundle/Contents/Resources
It appears that change in how the installer deploys the plugin bundle breaks code signature verification. To provide additional context, I’ve found publicly available installer packages from other vendors that contain installer plugins with a similar structure and they also have the same issue. For example, Avast's macOS installer package contains an installer plugin as well: https://www.avast.com/free-mac-security#mac. This suggests that the issue may not be specific to our installer package and could potentially affect other third-party installer plugins as well.
Hey @dverevkin , I am also facing the same issue, did you find any workaround or any fix around this?
It is happening on the latest beta (27.0 Beta (26A5425a)) too — I tested today.
Same amfid signature as yours (Code=-420 on the plugin executable in /private/tmp/com.apple.installerXXXXXX/, "Broken signature with Team ID fatal", and the UNIX error 62/ELOOP backtraces), and I can confirm the symlinked Contents/ layout
you described — codesign -vvv on the /tmp bundle gives "Too many levels of symbolic links" here too.
same binaries work fine on macOS 26.6.
Also filed via Feedback Assistant (FB24601496).
I’ve found that code signature verification fails with an ELOOP
Yowsers!
As I said on anonymoussingh’s thread, it’s hard to imagine this being anything other than a bug. Thanks for updating your bug report (FB24415432) with your latest findings.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Additional findings on this issue
We've dug into this a bit further and have two new data points:
- Onset: This behavior started appearing from macOS 26.7 onward — earlier versions were unaffected.
- Repro depends on how the pkg is launched: Running the .pkg inside the mounted DMG (installing directly from the mounted volume) does not show our installer plugin panes. But if the same .pkg is copied out of the DMG to a regular folder — Desktop, Downloads, etc. — the Installer runs it with all plugin panes rendering normally.
Tested and confirmed on both macOS 26.7 and macOS 27.