open(/var/db/DetachedSignatures) - Undefined error:0

How to fix this?

Do you need to fix this? Does it actually result in some sort of problem? If not, I’m inclined to treat this as log noise.

OTOH, if there is an actual problem, please describe its symptoms?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Having the same problem with some build failures where Xcode can't sign the app at the end of our CI process.

I think it’s unlikely that these things are related. /var/db/DetachedSignatures is only used if the system has to synthesise a code signature for an app that doesn’t have one (for example, you add a firewall exception for an app that’s unsigned). The fact that it’s missing on standard user systems is not an error.

I think you need to dig deeper into the code of your signing problem. My experience is that many CI systems run your build scripts in odd environments, and that causes keychain operations to fail.

For example, they run in a global context and then explicitly set the user ID to that of your build user. This is generally inadequate on macOS because it doesn’t switch all the other Mac-specific execution context. See the Execution Contexts section of Technote 2083 Daemons and Agents for more background on the challenges here.

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

I have the same problem (Xcode 12.3, MacOS 10.15 Catalina and 11.1 Big Sur).

Our code (a security tool based on the new EndpointSecurity framework) attempts to extract some code-signing information for processes as part of logic that determines whether or not to authorize some user actions)

So we execute

Code Block 
CFDictionaryRef attributes = (bridge CFDictionaryRef)@{(bridge NSString *)kSecGuestAttributePid : [NSNumber numberWithInt:self.pid] };
SecCSFlags options = kSecCSDefaultFlags; 
status = SecCodeCopyGuestWithAttributes(NULL, attributes, options, &dynamicCode);

and then do some verifications on the dynamicCode -- however, we're flooded with the same logs as the OP, plus, for some reason - despite the method returning success, OS hangs and kills our process immediately at that point (EndpointSecurity clients have this harsh reaction to just about anything, including any attempt to debug, or breakpoint, or run with instruments, or experience certain exceptions etc.). When run outside of the ES context - the code runs just fine, but logs are still emitted, for each execution of the SecCodeCopyGuestWithAttributes

When run outside of the ES context - the code runs just fine, but logs
are still emitted, for each execution of the
SecCodeCopyGuestWithAttributes

Right, which is evidence to support my earlier assertion that this is just On log noise.

EndpointSecurity clients have this harsh reaction to just about
anything, including any attempt to debug, or breakpoint, or run with
instruments, or experience certain exceptions etc

Indeed they do. ES clients live in a privileged position within the system and thus the system places strict constraints on what they can do.

and kills our process immediately at that point

Does that yield a crash report?

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

This is not an answer. I wanted to note that my errors stem from the use of NSTask.

I have created some helper build scripts in swift to automate a new app build. These are compiled and can be run from within Xcode as well or as useful command lines.

It will spawn an NSTask (Now renamed Process in swift) where I would do something like this

/usr/bin/codesign --remove-signature "/my file....."

If I ran this command in terminal, all works well. Buy if I ran under my script, using an NSTask I see errors like the harmless [logging-persist] and others

It seems as if the apple tools are not happy running as child processes under my NSTask. Any advice on how to configure NSTask properly.

I'm seeing this same error message when trying to use startosinstall on a macOS 12.0.1 system. The startosinstall doesn't do anything after this message. So, it's either related or something else is going wrong after it and therefore not being logged.

nvm ... it's Apple's settings they sneaked in for M1 Macs requiring a password for the install, despite being run by sudo (root). Having to put the password in a script is a step backwards indeed ...

I kept getting that too (XCode 13.4.1 OS 12.4 M1 iMac).

This worked for me:

sudo touch /var/db/DetachedSignatures

in Terminal.