codesign

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

Looks like I wasn't using the right SHA1 for my cert when calling codesign. I figured I could get the cert information by using security export-smartcard -i [card] | grep sha1 sha1 : After a bit of string manipulation: DC5F8D160FCD0342AE061D70716E114BD438D668 Now when I'm calling codesign -s DC5F8D160FCD0342AE061D70716E114BD438D668 -f foobar I can see the sign method of my TKTokenSession being called. tl;dr: New identity doesn't show up in Keychain, but it doesn't mean the OS can't use it. However you need to make sure you're using the right SHA1.

automation package installer script I'm using looks like this: set -euo pipefail APP_NAME=Runetale.app APP_BUNDLE=build/macos/Build/Products/Release/${APP_NAME} DEV_ID_APP_CERT=Developer ID Application: MYTEAMID DEV_ID_INSTALLER_CERT=Developer ID Installer: MYTEAMID APP_VERSION=1.0.0 APP_BUNDLE_ID=com.runetale.desktop # Apple credentials for notarization APPLE_ID= TEAM_ID= APP_SPECIFIC_PW= # clean and build rm -rf build flutter clean flutter build macos --release # Ensure the app exists if [ ! -d $APP_BUNDLE ]; then echo Error: $APP_BUNDLE not found. Make sure the app bundle is present. exit 1 fi echo Starting code signing for $APP_BUNDLE... # copy Runetale.app codesign -d -vvv build/macos/Build/Products/Release/Runetale.app ditto $APP_BUNDLE $APP_NAME # copy entitlements codesign -d --entitlements Release.entitlements --xml Runetale.app codesign -d --entitlements PacketTunnelRelease.entitlements --xml Runetale.app/Contents/Library/SystemExtensions/com.runetale.desktop.PacketTunnel.

@DTS Engineer Thank you. I read the documentation provided by Apple engineers. I was able to create the installer successfully and launch the application. However, when I try to connect to the VPN, I get the following error: default 16:53:58.419606+0900 Runetale Saving configuration Runetale with existing signature (null) error 16:53:58.420440+0900 Runetale Failed to save configuration Runetale: Error Domain=NEConfigurationErrorDomain Code=10 permission denied UserInfo={NSLocalizedDescription=permission denied} error 16:53:58.420474+0900 Runetale Failed to save configuration: Error Domain=NEVPNErrorDomain Code=5 permission denied UserInfo={NSLocalizedDescription=permission denied} error 16:53:58.420407+0900 nehelper Runetale Failed to obtain authorization right for 3: no authorization provided Is there any possible reason for this? The entitlements look like this: App entitlements com.apple.application-identifier myteamid.com.runetale.desktop com.apple.developer.networking.networkextension packet-tunnel-

To recap, my Ruby files for the app are located under ./app, with the gems being vendored. This library is located at ./app/vendor/bundle/ruby/3.3.0/gems/libui-0.1.2-arm64-darwin/vendor/libui.dylib. I'm curious if I should codesign the libui.dylib before building the binary with Tebako? If so, would I still need to codesign the Contents/Frameworks files under the app bundle? (I'm assuming yes on this latter point.) Thanks in advance for your suggestions.