Hi everyone, I'm struggling to access a certificate stored in keychain when using LaunchDaemons and would appreciate any advise to improve over my current workaround with an agent. I'm maintaining an M1-based Mac Mini with macOS Big Sur 11.4 as a build client for Gitlab CI. The machine makes itself known to the orchestrating Gitlab server through the so-called gitlab-runner process which regularly polls the Giltab server for build job requests. It would then eventually call xcodebuild to generate artifacts and upload them to Gitlab. In order to have this process startup automatically, I've loaded it through a /Library/LaunchDaemons/gitlab-runner.plist file in launchctl. This setup has been working greatly for months, making the build client immediately available after a reboot without the need to log into it. I've now started to deploy codesign tasks to the build client and encountered issues with keychain access to the certificate. I installed the certificate and performed security find-identity -v -p codesigning in the Terminal to validate correct installation. I have ensured that the codesign tasks succeed when performed through Terminal manually. A popup was shown on first try about codesign wanting to access to the local keychain, which I always allowed. Codesign then reported success: signed Mach-O universal. The behavior is different for my LaunchDaemons-based codesign tasks (spawned under the same user). I've tried multiple permutations for sudo launchctl load -w /Library/LaunchDaemons/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=true, System keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: FAIL (error: The specified item could not be found in the keychain.) SessionCreate=false, System keychain: FAIL (errSecInternalComponent) I've then tried a user agent launchctl load -w ~/Library/LaunchAgents/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: OK (Popup -> Always allow, signed Mach-O universal) So apparently, the last variant works reliably. However, it has the severe downside that I now need to log in the user after a reboot in order to kick off the agent. Is there a way to make this work with /Library/LaunchDaemons, possibly through some plist property? As a test I've tried to "Allow all applications" to access the private key associated with the Certificate but that didn't change anything. Best regards Maik

Unable to notarize app due to Please use diagnostic mode to check connectivity. You need to have outbound access to TCP port 443 & An exception has occurred: Remote host terminated the handshake & Could not connect to Apple's web service

Even though I have valid and multiple Developer ID Application certs in my apple developer account, I am facing this issue. Could any know how to overcome this?

I have an app not made in Xcode, which I notarize. I have no problem notarizing it in a Catalina VM I run with Xcode 11.4 but on my BigSur MacBook Pro with Xcode 12.5.1 (the latest) I cannot code sign. I get the message "resource fork and finder info and similar detritus not allowed". I get this even if I do Xattrib -cr first to clear it all. Code signing my app takes a few code signing commands. The first few go OK but then on the next couple it immediately says that error message as if the first ones inserted more detritus. I cannot finish code signing. First I do this: xattr -cr "/Users/richard/Desktop/Deploying/Jyotish Studio 5/Jyotish Studio 7.1.app" Then I do this: codesign -f --deep -o runtime --entitlements /Users/richard/Desktop/Deploying/standard_entitlements.plist --timestamp --verbose -s "Developer ID Application: Das Goravani (K6ZXXXXRU)" /Users/richard/Desktop/Deploying/Jyotish\ Studio\ 5/Jyotish\ Studio\ 7.1.app that one above signs everything, and it seems to insert some detritus because when I issue the next one to seal up the app it gives the error now, but note it does not give the error using the exact same commands in 11.4 on Catalina. Here's the command that gives the error after doing the above: codesign -f -o runtime --entitlements /Users/richard/Desktop/Deploying/standard_entitlements.plist --timestamp --verbose -s "Developer ID Application: Das Goravani (K6XXXXXRU)" /Users/richard/Desktop/Deploying/Jyotish\ Studio\ 5/Jyotish\ Studio\ 7.1.app Why do the exact same commands work on 11.4 Xcode and Catalina on a Virtual machine I run and not on BigSur with Xcode 12.5.1? I cannot now notarize if I use only my main Mac main OS which is BigSur.. can't notarize. I have to run the VM, I have to keep it around, which takes up a lot of drive space, just for notarizing, which bugs me. Note that I AM doing the xattrib -cr command first to clear all finder info etc.. but somehow it comes back due to signing the app. I also downloaded and tried an app for cleaning detritus from the app, it's called Clean Detritus.. I tried that, ran it, and got the same problem anyway. Please help.

We're attempting to update on of our apps from Unity 2019 to Unity 2021. Attempting to notarize the built app fails. This is on our main build machine running macOS Catalina 10.15.7. An independent contractor working with us builds the exact same project on his laptop running macOS Catalina 10.16.7. He can notarize the app successfully. Now, her's the interesting part. As a test, the two of us built new apps and transferred them to each other's systems. The app transferred from the build machine (10.15.7) to the laptop (10.16.7) notarized successfully, while the one transferred the other way failed. Would love to get some insight on what's going on. Log output: { "logFormatVersion": 1, "jobId": "b48937dd-37cb-4833-9d2b-5c64b5b9f75c", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "AppName.zip", "uploadDate": "2021-08-16T20:01:39Z", "sha256": "78a71ec70e906480b9817580672b59e4a4c5f7ccb46b292314a6ad4a6c0b1acc", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "AppName.zip/AppName.app/Contents/MacOS/AppNameGame", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] } And our notarization script: export APPLICATION_NAME=AppName export APPLICATION_FILE=${APPLICATION_NAME}.app export APPLICATION_ZIP=${APPLICATION_NAME}.zip export APPLICATION_ENTITLEMENTS=${APPLICATION_NAME}.entitlements export APPLICATION_BUNDLE_ID=unity.Dev.AppName export APPLE_USERNAME=user@name.com export APPLE_PASSWORD=NOT_A_REAL_PASSWORD export APPLE_PROVIDER=AppProducer export APPLE_SIGNATURE="Developer ID Application: AppProducer, Inc. (ABCD123456)" rm ${APPLICATION_NAME}.zip codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/CustomRulesLib-OSX.bundle/Contents/MacOS/CustomRulesLib-OSX" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/steam_api.bundle/Contents/MacOS/libsteam_api.dylib" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/unitypurchasing.bundle/Contents/MacOS/unitypurchasing" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" ${APPLICATION_FILE} zip -q -r ${APPLICATION_ZIP} ${APPLICATION_FILE} xcrun altool --notarize-app --username ${APPLE_USERNAME} --password ${APPLE_PASSWORD} --asc-provider ${APPLE_PROVIDER} --primary-bundle-id ${APPLICATION_BUNDLE_ID} --file ${APPLICATION_ZIP}

I have an Avalonia application I want to distribute in-house. (Avalonia is a crossplatform GUI based on dotnet) I followed the guide here: (https://docs.avaloniaui.net/docs/distribution-publishing/macos) My notarization succeeds and I can get the notarization info using xcrun altool --notarization-info UUID -u myappleid No errors getting notarization info. Date: 2021-08-18 07:29:13 +0000 Hash: d1e8825c6571fff0bbcd11c5496b2a84ac1ad8b8a62b77771cde7a0eca286de9 LogFileURL: <Log URL> RequestUUID: <UUID> Status: success Status Code: 0 Status Message: Package Approved If I run codesign -dvvv "/Path/to/my app.app" I can see Executable=/Path/to/my app.app/Contents/MacOS/my app Identifier=com.my.app Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=1126 flags=0x10000(runtime) hashes=24+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c CandidateCDHashFull sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e Hash choices=sha256 CMSDigest=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e CMSDigestType=2 CDHash=3e5d21fdc6948b0d6cff4c94cd89fa441197182c Signature size=8980 Authority=Developer ID Application: company name (<TEAM ID>) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=18 Aug 2021 at 5:26:47 pm Info.plist entries=11 TeamIdentifier=<TEAM ID> Runtime Version=10.15.0 Sealed Resources version=2 rules=13 files=413 Internal requirements count=1 size=188 The cdhash 3e5d21fdc6948b0d6cff4c94cd89fa441197182c is present in the developer log of notarization twice: { "path": "my_app.zip/my app.app/Contents/MacOS/my app", "digestAlgorithm": "SHA-256", "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c", "arch": "x86_64" }, { "path": "my_app.zip/my app.app", "digestAlgorithm": "SHA-256", "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c", "arch": "x86_64" } When I run the spctl /usr/sbin/spctl --assess --type exec -vv "/Path/to/my app.app" I get /Path/to/my app.app: accepted source=Notarized Developer ID origin=Developer ID Application: company name (<TEAM ID>) My codesign was run using Avalonia's bash script with added --deep #!/bin/bash APP_NAME="/Path/to/my app.app" ENTITLEMENTS="/Path/to/entitlements/my_app.entitlements" SIGNING_IDENTITY="Developer ID Application: company name (<TEAM ID>)" find "$APP_NAME/Contents/MacOS/"|while read fname; do if [[ -f $fname ]]; then echo "[INFO] Signing $fname" codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$fname" fi done echo "[INFO] Signing app file" codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$APP_NAME" After notarization I receive an e-mail from Apple that my software was 'successfully notarized'. However, when I run xcrun stapler staple "/Path/to/my app.app" I get Processing: /Path/to/my app.app Could not validate ticket for /Path/to/my app.app The staple and validate action failed! Error 65. If I run stapler with -v I can see that the ticket is successfully downloaded.

We're attempting to update on of our apps from Unity 2019 to Unity 2021. Attempting to notarize the built app fails. This is on our main build machine running macOS Catalina 10.15.7. An independent contractor working with us builds the exact same project on his laptop running macOS Catalina 10.15.7. He can notarize the app successfully. Now, her's the interesting part. As a test, the two of us built new apps and transferred them to each other's systems. The app transferred from the build machine to the laptop notarized successfully, while the one transferred the other way failed. Would love to get some insight on what's going on. Why does notarization succeed on one machine but fail on another? Log output: { "logFormatVersion": 1, "jobId": "b48937dd-37cb-4833-9d2b-5c64b5b9f75c", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "AppName.zip", "uploadDate": "2021-08-16T20:01:39Z", "sha256": "78a71ec70e906480b9817580672b59e4a4c5f7ccb46b292314a6ad4a6c0b1acc", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "AppName.zip/AppName.app/Contents/MacOS/AppNameGame", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] } And our notarization script: export APPLICATION_NAME=AppName export APPLICATION_FILE=${APPLICATION_NAME}.app export APPLICATION_ZIP=${APPLICATION_NAME}.zip export APPLICATION_ENTITLEMENTS=${APPLICATION_NAME}.entitlements export APPLICATION_BUNDLE_ID=unity.Dev.AppName export APPLE_USERNAME=user@name.com export APPLE_PASSWORD=NOT_A_REAL_PASSWORD export APPLE_PROVIDER=AppProducer export APPLE_SIGNATURE="Developer ID Application: AppProducer, Inc. (ABCD123456)" rm ${APPLICATION_NAME}.zip codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/CustomRulesLib-OSX.bundle/Contents/MacOS/CustomRulesLib-OSX" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/steam_api.bundle/Contents/MacOS/libsteam_api.dylib" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" "${APPLICATION_FILE}/Contents/Plugins/unitypurchasing.bundle/Contents/MacOS/unitypurchasing" codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements ${APPLICATION_ENTITLEMENTS} --sign "${APPLE_SIGNATURE}" ${APPLICATION_FILE} zip -q -r ${APPLICATION_ZIP} ${APPLICATION_FILE} xcrun altool --notarize-app --username ${APPLE_USERNAME} --password ${APPLE_PASSWORD} --asc-provider ${APPLE_PROVIDER} --primary-bundle-id ${APPLICATION_BUNDLE_ID} --file ${APPLICATION_ZIP}

I'm trying to get setup using notarytool and I keep getting back this message... Error: Missing value for '-i <issuer>' Usage: notarytool submit <options>   See 'notarytool submit --help' for more information. I'm using the form... xcrun notarytool submit \<path to product\> --verbose --apple-id \<an Apple ID\> --password \<Application Password\> --team-id \<our Team ID\> --progress --wait All the examples I can find do not use the -I parameter so I'm not sure why it want it. So, how do I get the Issuer ID so I can put it in and see if it makes things happy? I see posts saying it is accessible at this URL... https://appstoreconnect.apple.com/access/api But for me it is not. I also saw a reference saying that the team Agent has to enabled this functionality. But I'm not sure how they would do that. I am an Admin on the account but not the Account Holder. Is this really necessary for making the call to notarytool or is there something else going on here? So, does the Account Holder need to click a box somewhere so I can see the Issuer ID? If so, can someone give me specifics that I can pass on to our Account Holder? Any other thoughts that might help me?

Been 5 days on notarisation issues and nowI am stuck and cannot move on. In previous attempts I was able to re-try and re-try but now are stuck when I do: xcrun altool --notarize-app --primary-bundle-id com.company.*** --username myemail --password "@keychain:altool" --file pathto\mypackage.pkg -asc-provider *** Snapshot: Error: [2021-08-31 15:13:35 SGT]  INFO: Performing authentication of package net.company.xx.itmsp ... [2021-08-31 15:13:35 SGT] DBG-X: Memory: [JVM] 974M free, 1024M total, 2048M max [System] (Physical) 1105M free, 16384M total (Swap) 0 free, 0 total [2021-08-31 15:13:35 SGT]  INFO: JSON:{"msg":{"phase":"Upload","count":2,"description":"Analyzing metadata","index":1},"messageType":"VerifyProgress"} [2021-08-31 15:13:35 SGT] DBG-X: Deflated 572 bytes to 452 [2021-08-31 15:13:35 SGT] DBG-X: Using operation named: validateMetadata [2021-08-31 15:13:35 SGT] DBG-X: Apple's web service operation input parameters: [2021-08-31 15:13:35 SGT] DBG-X:  parameter Application = iTMSTransporter [2021-08-31 15:13:35 SGT] DBG-X:  parameter BaseVersion = 2.1.0 [2021-08-31 15:13:35 SGT] DBG-X:  parameter Client = altool [2021-08-31 15:13:35 SGT] DBG-X:  parameter ClientVersion = 4.050 (1210) [2021-08-31 15:13:35 SGT] DBG-X:  parameter Files = [XX.pkg, metadata.xml] [2021-08-31 15:13:35 SGT] DBG-X:  parameter ItcProviderName = XX [2021-08-31 15:13:35 SGT] DBG-X:  parameter Metadata =   <software_assets     app_platform="osx"     primary_bundle_identifier="net.copmany.xx">            <data_file>         <file_name>XX.pkg</file_name>         ecebcd93615806456d8bc8c550d1267c         17615853       </data_file>        </software_assets> [2021-08-31 15:13:35 SGT] DBG-X:  parameter MetadataChecksum = f621fe2b214b7d633553d5e8c6358b03 [2021-08-31 15:13:35 SGT] DBG-X:  parameter MetadataCompressed = (suppressed) [2021-08-31 15:13:35 SGT] DBG-X:  parameter MetadataInfo = {app_platform=osx, primary_bundle_identifier=net.copmany.XX, device_id=, bundle_identifier=, packageVersion=software5.9, apple_id=, asset_types=[developer-id-package], bundle_version=, bundle_short_version_string=} [2021-08-31 15:13:35 SGT] DBG-X:  parameter OSIdentifier = Mac OS X 11.5.2 (x86_64); jvm=14.0.2+12-iTunesOpenJDK-5; jre=14.0.2+12-iTunesOpenJDK-5; arch=arm64; rosetta=true [2021-08-31 15:13:35 SGT] DBG-X:  parameter PackageName = net.company.XX.itmsp [2021-08-31 15:13:35 SGT] DBG-X:  parameter PackageSize = 17616425 [2021-08-31 15:13:35 SGT] DBG-X:  parameter StatisticsClientStartDateTimeZoneISO = 2021-08-31T15:13:35+08:00 [2021-08-31 15:13:35 SGT] DBG-X:  parameter TransporterArguments = -m upload -u m -vp json -DTxHeaders=eyJqZW5nYSI6dHJ1ZX0= -sessionid @env:7F9601C8-4ABC-4F9F-A50D-36846F20C179 -sharedsecret hidden value -itc_provider XX -f /var/folders/b3/q74qf15d43561dlmf2g6y86r0000gn/T/A6CB0D21-BA1F-4164-9B09-75DC5E573BBC/net.xx.xx.itmsp -indicator true -v eXtreme -Dtransporter.client=altool -Dtransporter.client.version=4.050 (1210)yemail [2021-08-31 15:13:35 SGT] DBG-X:  parameter Version = 2.1.0 [2021-08-31 15:13:35 SGT] DBG-X:  parameter iTMSTransporterMode = upload [2021-08-31 15:13:35 SGT]  INFO: id = 20210831151335-486 [2021-08-31 15:13:35 SGT]  INFO: iTMSTransporter Correlation Key: 60c9b78b-22a5-487e-a336-c7a83509fa85-0001 [2021-08-31 15:13:35 SGT] DEBUG: DataCenter: contentdelivery02.itunes.apple.com [2021-08-31 15:13:35 SGT] DBG-X: Apple's web service operation return value: [2021-08-31 15:13:35 SGT] DBG-X:  parameter EnableJWTForAllCalls = false [2021-08-31 15:13:35 SGT] DBG-X:  parameter MinimumFileSizeThresholdForCheckum = 104857600 [2021-08-31 15:13:35 SGT] DBG-X:  parameter SoftwareMediaDescriptionFormat = binary [2021-08-31 15:13:35 SGT] DBG-X:  parameter RestartClient = false [2021-08-31 15:13:35 SGT] DBG-X:  parameter SoftwareMediaDescriptionThresholds = {in-app-purchase-content={extensions=[pkg], size=100000000}, ccats={extensions=[pdf], size=100000000}, product-archive={extensions=[pkg], size=100000000}, developer-id-package={extensions=[zip, pkg, dmg], size=100000000}, bundle={extensions=[zip, ipa], size=100000000}, large-icon={extensions=[jpg, png, jpeg], size=100000000}} [2021-08-31 15:13:35 SGT] DBG-X:  parameter Success = false [2021-08-31 15:13:35 SGT] DBG-X:  parameter Errors = [ERROR ITMS-90732: "The software asset has already been uploaded. The upload ID is 0a92b382-7888-40f3-8d94-8fb05cc50267" at SoftwareAssets/EnigmaSoftwareAsset] [2021-08-31 15:13:35 SGT] DBG-X:  parameter FilesToUpload = [metadata.xml, XX.pkg] [2021-08-31 15:13:35 SGT] DBG-X:  parameter AssetsToDescribe = [] [2021-08-31 15:13:35 SGT] DBG-X:  parameter Checksums = {XX.pkg=XX} [2021-08-31 15:13:35 SGT] DBG-X:  parameter FileSizes = {XX.pkg=17615853} [2021-08-31 15:13:35 SGT] DBG-X:  parameter ErrorCode = 1102 [2021-08-31 15:13:35 SGT] DBG-X:  parameter ErrorMessage = ERROR ITMS-90732: "The software asset has already been uploaded. The upload ID is XX-7888-40f3-8d94-8fb05cc50267" at SoftwareAssets/EnigmaSoftwareAsse  (1102) [2021-08-31 15:13:35 SGT] DBG-X:  parameter ShouldUseRESTAPIs = false [2021-08-31 15:13:35 SGT] ERROR: ERROR ITMS-90732: "The software asset has already been uploaded. The upload ID is XX-7888-40f3-8d94-8fb05cc50267" at SoftwareAssets/EnigmaSoftwareAsset [2021-08-31 15:13:35 SGT] DBG-X: The error code is: 1102 [2021-08-31 15:13:35 SGT]  INFO: JSON:{"msg":{"phase":"Upload","count":2,"description":"Operation failed","index":2},"messageType":"VerifyProgress"} [2021-08-31 15:13:35 SGT] DBG-X: Returning 1  Out: Package Summary:   1 package(s) were not uploaded because they had problems: /var/folders/b3/***/T/A6CB0D21-BA1F-4164-9B09-75DC5E573BBC/net.company.***.itmsp - Error Messages: ERROR ITMS-90732: "The software asset has already been uploaded. The upload ID is XX-7888-40f3-8d94-8fb05cc50267" at SoftwareAssets/EnigmaSoftwareAsset *** Error: Unable to notarize app. *** Error: ERROR ITMS-90732: "The software asset has already been uploaded. The upload ID is XX-7888-40f3-8d94-8fb05cc50267" at SoftwareAssets/EnigmaSoftwareAsset (-18000)

The "Developer ID Notary Service" is taking forever. Is there any issue?

Hi there, We are developing an applicaton that can update itself. For example, we have two version 1 & 2. Both of them are signed, notarlized and stapled mac app bundle. When the version 1 find that there is a new version. It would download the difference. Then open another application named updater we developed. The updater use some posix function such as fopen, fwrite, chmod and link to copy/delete files to make the original one as the same as the version 2. The problem comes out here. When we open the updated one, the syslog says that binary is improperly signed. I don't know which step is incorrect. I make a copy of this app, it works perfectly. I guess there is something wrong with the application updater. We tried make the updater to be a single executable file or an signed, notarlized and stapled application bundle and still not work. After read some threads I still could not find out what is it. Hope someone could help me about this. Thanks in advance!

Code Sign is successful: codesign -vvv --deep --strict kudilpass-3.0.0.dmg kudilpass-3.0.0.dmg: valid on disk kudilpass-3.0.0.dmg: satisfies its Designated Requirement However, notarization fails "issues": [ { "severity": "error", "code": null, "path": "kudilpass-3.0.0.dmg/kudilpass.app/Contents/MacOS/kudilpass", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "kudilpass-3.0.0.dmg/kudilpass.app/Contents/runtime/Contents/MacOS/libjli.dylib", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ] Any help is appreciated. Thanks

Hi, Seeing inconsistency while notarizing a pkg file. It doesn't always work stapling the exactly same package. hostname:~ user$ stapler staple tmpgprjgljx.pkg Processing: /Users/user/tmpgprjgljx.pkg Processing: /Users/user/tmpgprjgljx.pkg The staple and validate action worked! hostname:~ user$ stapler staple tmpgprjgljx.pkg Processing: /Users/user/tmpgprjgljx.pkg CloudKit query for tmpgprjgljx.pkg (1/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) failed due to "(null)". Could not find base64 encoded ticket in response for 1/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx The staple and validate action failed! Error 65. In the log above, stapling worked the first time but failed the second time! We automated the whole process a few months ago and it's been stable until today. Cheers

We use the apple notary service to notarize our binaries and we’d like to be able to get slack notifications in the case that there are notary service outages and those affect our pipeline builds. We find ourselves spending time inspecting the issue / bug to find out that it is apple service outage. It would be really nice to be able to get notifications that there are outages occurring so we don’t spend the extra time figuring out why builds are timing out. Currently there is no rss feed on the developer systems page where we can easily add to slack as part of their connect tool service. Is there anything on the timeline to add an rss feed to the system status page? Or will the apple status page potentially be added to Statuspage? (Atlasssian product)

I represent a number of "Omnis Developers", people who write apps with Omnis, a RAD, high level language, that does not compile, but rather, we distribute an Omnis Runtime app with our library of code that is interpreted at runtime. We create business apps mainly. To distribute our apps we include our library of code with a copy of the Omnis runtime app. So when we go to code sign and notarize our apps we are actually signing and notarizing the Omnis app, which we did not create, we license it. Omnis Inc. creates and maintains their executable that we license and distribute. So when we approach Notarization, we are not the developers of the app we are notarizing. We do not intimately know it's insides, where is the code, and what doesn't need to be code signed. We were provided a path to notarization by Omnis Inc and it worked fine, still works fine, under Catalina and Xcode 11. That method included using the --deep command. It worked. Omnis is a non-standard app I believe, in terms of where it has code inside it. Under BigSur and Xcode 12 the --deep command inserts detritus.. you get that message that finder information and similar detritus is not allowed. You cannot finally sign the main app after signing ALL of it's insides. You get stuck. Instead of using the --deep command Apple recommended to me, or one engineer did, that I sign the insides of the app manually. I did that, but not knowing what to sign I signed everything. I got the "similar detritus" problem. I am petitioning Omnis to give me a list of folders inside the app that actually need to be code signed. I am hoping that by signing only some things that I will not get the detritus message. I am posting about this here in case anyone has anything to tell me that will help me. I have the work around of running a Catalina Virtual Machine and Xcode 11.. that is what I am doing presently. One developer pointed out that Apple will probably not allow code signing from older OS's eventually.. and we will be really stuck. So I am working on this issue presently. Either the --deep command has to work and not insert detritus, or signing everything has to not insert detritus, or a list of things to sign will not insert detritus.. one of these has to give way to signing without that message coming up. This is of concern to many Omnis developers worldwide. We have the Catalina workaround, but for how long? Sincerely, Das Goravani

Hello all , I'm attempting to sign a small python GUI , albeit after multiple attempts I can't seem to get it to work. When I sign it locally, it seems that it's working. (When I attempt to sign again it says "already been signed"). Once I send the app to apple it says it failed and it has not been signed. If anyone has signed a .app file created with py2app ; can you please assist ?