“codesign”

also can confirm that I can take my bosses p12 files and set them up on my computer using this script KEYCHAIN_PATH1=$HOME/Library/Keychains/tmpsed1.keychain-db KEYCHAIN_PASSWORD1=$(openssl rand -base64 12) security create-keychain -p $KEYCHAIN_PASSWORD1 $KEYCHAIN_PATH1 security unlock-keychain -p $KEYCHAIN_PASSWORD1 $KEYCHAIN_PATH1 echo keychain-path=$KEYCHAIN_PATH1 echo keychain-password=$KEYCHAIN_PASSWORD1 #DEV_ID_APPLICATION=$(mktemp) #echo $DEV_ID_APPLICATION #base64 -i app.p12 | base64 -d >$DEV_ID_APPLICATION #cat $DEV_ID_APPLICATION security import app.p12 -f pkcs12 -k $KEYCHAIN_PATH1 -P password -T /usr/bin/codesign -T /usr/bin/security export DEV_ID_INSTALLER=$(mktemp) base64 -i installer.p12 | base64 -d >$DEV_ID_INSTALLER security import installer.p12 -f pkcs12 -k $HOME/Library/Keychains/tmpsed1.keychain-db -P “password” -T /usr/bin/pkgbuild -T /usr/bin/security -T /usr/bin/productbuild rm $DEV_ID_INSTALLER security set-key-partition-list -S apple-tool:,apple: -s -k $KEYCHAIN_PATH1 $K

[quote='837189022, LinuxProg, /thread/782331?answerId=837189022#837189022, /profile/LinuxProg'] It would be very useful for Apple to add a test VM creation CLI to the developer toolkit [/quote] I tend to agree but, given that current reality, I encourage you to explore the raft of third-party options out there [1]. As to your original issue, adding an extension is the right option here. macOS draws a clear distinction between bundled and non-bundle code. This really matters when comes to code signing. See the discussion is Creating distribution-signed code for macOS. That Java runtime is signed as a bundle: % codesign -d -vvv jdk-21.0.7+6-jre Executable=/Users/quinn/Desktop/jdk-21.0.7+6-jre/Contents/MacOS/libjli.dylib Identifier=net.java.openjdk.jre Format=bundle with Mach-O thin (arm64) ^^^^^^ However, the exact definition of what constitutes a bundle is more squishy then it should be. It seems that codesign and Gatekeeper disagree as to whether the file name extension is required, which is

Yeah, this stuff is complex )-: Let me clarify this by example. My go-to suggestion for setting this up is to do what Xcode does. In fact, we have that in the official documentation, namely Signing a daemon with a restricted entitlement. If you follow that process and build the test project with Xcode, you see this: % codesign -d --entitlements - Test782415.app … [Dict] [Key] com.apple.application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.Test782415 [Key] com.apple.developer.endpoint-security.client [Value] [Bool] true [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] com.apple.security.get-task-allow [Value] [Bool] true % security cms -D -i Test782415.app/Contents/embedded.provisionprofile | plutil -p - { … Entitlements => { com.apple.application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test782415 com.apple.developer.endpoint-security.client => 1 com.apple.developer.team-identifier => SKMME9E2Y8 keychain-access-groups =>

Thank you. I see, so I was using the wrong type of certificate and that's why notarization was failing. Thank you for your help so far. With the correct cert, I have hit another blocker: I sent off the certificate signing request and downloaded the correct certificate and imported it into keychain access. It has the name: Developer ID Application: COMPANY REDACTED (REDACTED ID) Green check mark: This certificate is valid. I see other information like the issuer: Developer ID Certification Authority Apple Certification Authority This matches what you mentioned above. Just making sure. And, I have removed the old certificate from keychain access and disk so it won't interfere. I mention this because of the below blocker. To my knowledge, this does not look like a self signed cert. Which... would be weird as I downloaded it from the certificate signing request. When I go to code sign now: codesign -s REDACTED ID SAME AS DEVELOPER ID APPLICATION CERT -f --timestamp -o runtime -i com.redacted.hello_world

Dietmar, I had a similar issue some time ago. It sounds like you've navigated a complex signing process, and you're very close! The error message clearly points to an issue with a debug symbol file (.dSYM) within your application bundle having an Apple-reserved bundle identifier (com.apple.xcode.dsym...). This typically happens when these files aren't properly handled during the deployment and signing process for third-party applications. Understanding the Error: The App Store Connect validation is rejecting your build because it found a .dSYM file with a bundle identifier that belongs to Apple. This suggests that either: Debug Symbols for Qt Plugins are Included Incorrectly: The .dSYM file for the libqtqmlcoreplugin.dylib (a Qt plugin) is being bundled in a way that retains Apple's internal identifier. Incorrect Handling of .dSYM Files during macdeployqt6: The macdeployqt6 tool might be copying these debug symbol files without the necessary modifications for App Store distribution. Strategies for Correctly M

The presence of code signing extended attributes is worrying, and it’s definitely something you should investigate and try to fix. It typically means that your code isn’t following the rules outlined in Placing Content in a Bundle, or you’re manually signing code and not following the process in Creating distribution-signed code for macOS. By way of explanation, code signing uses these extended attributes when it’s signing a data item as if it were code. As the data item doesn’t have a place to store the code signature, codesign places it in extended attributes. See TN3126 Inside Code Signing: Hashes for more on that. These extended attributes are a worry for two reasons. First, it’s not uncommon for code to be transferred via a channel that doesn’t preserve extended attributes. If that happens to code that uses extended attributes for its code signature, it breaks the code signature O-: The other issue is that the most common cause of this problem is a bad bundle structure and, quoting Placing Conte