codesign

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

[quote='781889021, perdrix52, /thread/781889, /profile/perdrix52'] I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that [/quote] That works for me (testing on macOS 15.4). Within the file sheet, press command-shift-G and enter /usr into the path. You can then navigate to /usr/bin and select codesign. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You have misunderstood the requirements here. Consider this: % codesign -dvv ./test_program.exe … Authority=Mac Developer: REDACTED NAME (REDACTED_ID) Mac Developer signing identities are for day-to-day development. The notary service requires that your code be signed by a Develeoper ID signing identity. For code that means Developer ID Application: TTT, where TTT identifies your team. If you’re signing code manually, I recommend that you read: Creating distribution-signed code for macOS Packaging Mac software for distribution Finally, Developer ID signing identities are precious, so you should manage them carefully. See The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com