“codesign”

I have a question about the amount of trust I should have in the team_id for an executable. I've been looking at the signing_id and team_id values in Apple's endpoint es_process_t, and almost all code follows the reverse naming scheme for their team_id. They have names like: com.getdropbox.dropbox com.microsoft.teams.helper com.apple.mdworker_shared com.apple.spctl But Google (at least) violates this reverse DNS pattern when signing many of their binaries. They have team IDs such as ksfetch GoogleSoftwareUpdateDaemon crashpad_handler Should I not trust the TLD (e.g., com.apple or com.microsoft) for the team ID? For example, could Google (or a malicious organization) sign their binary com.microsoft.ksfetch making me think it came from Microsoft?

Until I migrated to a new M1 machine running OSX 12, this used to work fine: codesign --sign --force --timestamp --options runtime Now, the exact same command (same cert, same binary) throws an error errSecInternalComponent internal error in Code Signing subsystem I found a vague reference that there might be some problems currently with Monterey in this regard and that ENABLE_BITCODE=NO might need to be used but it's not clear how to set that for CLI use like this. Any ideas much appreaciated.

Hi everyone, I am trying to build an app created by a software company that supplies its applications to us. They have their own Installation Maker for Mac. The builder requires an Apple Developer ID and the App password. I have created the App password, but I am lost with where I should find the Developer ID. We have a Team ID in the Dashboard and I also created a Developer ID Application certificate on my Mac via the dev website. I still cannot find the Developer ID. The new certificate is named Apple Development: Name Surname (XXYYYWWW). Is the ID in the brackets the Developer ID?

I have a react native application (that I deploy with expo). I am trying to run on ios. I had a app under a different account under the build identifier com.bcc.quickpass. There, the build was working fine. I transferred the app along with the build identifier to my current account. I then tried to run the app under my current account account using automated signing. The app builds but the following comes up: Here is the XCode Log: Could not launch “QuickPass” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: The operation couldn’t be completed. Unable to launch com.bcc.quickpass because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user. User Info: { DVTErrorCreationDateKey = 2022-12-06 06:01:22 +0000; DVTRadarComponentKey = 855031; IDERunOperationFailingWorker = DBGLLDBLauncher; RawUnderlyingErrorMessage = The operation couldnU2019t be completed. Unable to launch com.bcc.quickpass because it has an invalid code signature, inadequate

I'm trying to get an app notarized, which fails with this error: The signature of the binary is invalid. However, locally checking the signature does succeed: $ codesign -vvv --deep --strict TheApp.app […] TheApp.app: valid on disk TheApp.app: satisfies its Designated Requirement Performing this check on every single item in the app's MacOS folder also succeeds. Context: embedded prebuilt binaries Now, the app has something unusual about it: it embeds prebuilt binaries, arranged in various nested folders. So, the app bundle's MacOS folder actually contains another folder with a whole tree of executables and libraries: Removing these (before building) does fix the notarization issue, but obviously I'd like to keep them in. I did my best to properly sign these items: At build time, they're copied into the product by a Copy Files phase (but not signed), then signed by a script phase That signing uses the same signing identity as the running Xcode build, and enables the hardened runtime The app builds an

We have run into a very unique situation with codesigning and testing the apps under TestFlight under macOS 12 and macOS 13/14. We have existing apps on the macApp store and we are trying to basically update them. When we run the newly updated versions via Testflight under macOS 12, everything is working. However, the same apps under macOS 13/14 and Testflight crashes and we have narrowed it to a codesigned dylib issue of ours. We are getting a invalid code signature message when we try to load a dylib under macOS 13/14 and the app crashes as we cant get the dylib code pointer. Basically CFBundleGetFunctionPointerForName returns an invalid value. Just to explain we build our dylibs/bundles and codesign them outside - as these are built at the command line level and finally we package these within our apps under XCODE and go through the whole app building/archiving, code signing, validation and uploading that to the appstore. The crash log shows - Code Type: ARM-64 (Native) Parent Pr