Library Validation failed: reason: mapping process is a platform binary, but mapped file is not.

Hi, I've encountered similar error when loading my plugin which is being loaded as part of system.login.console authorization right

Code Block 
reason: mapping process is a platform binary, but mapped file is not

I've experienced this rejection only after the plugin was properly loaded.

Any idea why ? is this a signing issue ?

OK, there’s a general issue in play here (library validation prevents a process from loading code that’s signed by a different third-party developer) but this manifests in different ways. I can’t speak to the PDE side of things — printing is way outside of my bailiwick — but I can’t help you with an authorisation plug-in.

You wrote:

I've experienced this rejection only after the plugin was properly
loaded.

What do you mean by that? Is the authorisation plug-in actually running? Is this message actually correlated with some failure?

The reason I ask is that auth plug-ins are loaded by the system and the system is generally subject to library validation. However, the executables that load third-party auth plug-ins (authorizationhosthelper and SecurityAgentHelper, depending on whether the plug-in requires privileges or not) have explicitly disabled library validation, which is the only thing that allows them to load third-party plug-ins in the first place.

Oh, and what OS release are you seeing this on?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

I'm still seeing this error on very rare occasions when loading our authorization plugin for privilege escalation:

Replace: builtin:authenticate
With: TrusonaAuthorizationPlugin:trusonaLogin

The observed behavior is that clicking on the lock icon in "System Preferences > Security & Privacy" displays "Authenticating..." and just hangs there. Our plugin isn't being loaded. The solution I've found so far is to do a Restart. I've read "There's a code signing oddity in Apple systems where the kernel caches information about the signature and doesn’t flush that cache when you rewrite the Mach-O image file". The problem typically happens after installing a new version of the software on an M1 Mac mini hosted at Mac Stadium and running macOS Monterey. Once the problem occurs, it doesn't seem to matter which plugin image we use.

The problem appears so rarely it's hard to reproduce. Can you offer any ideas for how to resolve this or track down the underlying cause?

Can you offer any ideas for how to resolve this or track down the underlying cause?

A while back I got around to writing this up officially as Updating Mac Software.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

i've got a similar problem in a crontab to restart a process:

#! /bin/bash -f ps -ax |grep iRed2 |grep -v grep > /dev/null if [ "$?" != "0" ]; then /usr/bin/osascript -so -e "tell application "iRed2" to activate" echo "ired restarted" fi but i often get this error from osascript:

2024-05-30 13:40:01.932 osascript[14166:136122] Error loading /Library/QuickTime/EyeTV MPEG Support.component/Contents/MacOS/EyeTV MPEG Support: dlopen(/Library/QuickTime/EyeTV MPEG Support.component/Contents/MacOS/EyeTV MPEG Support, 0x0106): code signature in (/Library/QuickTime/EyeTV MPEG Support.component/Contents/MacOS/EyeTV MPEG Support) not valid for use in process: mapping process is a platform binary, but mapped file is not but afaik iRed2 has no connection to EyeTV, other than being referenced in many of iRed2's applescripts...wtf???

otherwise iRed2 starts up fine...other than having to be restarted, another wtf...

/usr/bin/osascript -so -e "beep"

produces the same error msg 93 times whytf does beep need quicktime???