I've just run into exactly the same problem and I am using altool. I used it a few months ago and it worked perfectly fine. Today I tried to use it again for an update we just released for OS X and I'm geting the error about signing contacts on line but there's nothing online for me to sign.Help!!!---------for the moment, you can work around it by submitting with altool

I just discovered this link --- (someone sent it to me) --- looks like it solves the problem --- why the heck is this not publicized better. https://xcodereleases.com/

By the way, I tried using codesign but that just tells me that it is replacing the existing signature, presumably meaning that the bundle is already signed.

Thanks for responding. Unfortunately, that's not the issue I had already tried that - I noted that while the main app got signed (so I didn't need to invoke codesign myself), a bunch of other stuff such as the sparkle framework did not seem to be signed - or at least the notarization failed with such messages as { "severity": "error", "code": null, "path": "GigPerformer4.zip/GigPerformer4.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/Autoupdate.app/Contents/MacOS/fileop", "message": "The binary is not signed with a valid Developer ID certificate.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "GigPerformer4.zip/GigPerformer4.app/Contents/Resources/grplscn", "message": "The signature does not include a secure timestamp.", "docUrl": null, "architecture": "x86_64" }, Yet, if I just archive from xcode and go through the "Developer ID (Distribute directly to customers)" process, I can upload to Apple notary service and the whole thing gets notarized properly I might add that during that process I'm informed that no profile is required for sparkle, grplscn etc) I'd be happy to pay someone a few hundred dollars to help me get this fixed but so far I haven't found anyone who seems to know how this all works.

I suspect that part of this issue is that these code items are not placed according to the rules Pretty sure everything is in the right place. But if they were not, why would everything work perfectly when archiving from Xcode? Having said that, I would export -exportArchive to handle this as well as Xcode Well, I have the entry /usr/bin/xcodebuild -exportArchive -archivePath "$ARCHIVE_PATH" -exportOptionsPlist "$EXPORT_OPTIONS" -exportPath "$EXPORT_PATH" -allowProvisioningUpdates but that doesn't seem to do anything. I recommend that you open a DTS tech support incident I did open a DTS tech support incident at the beginning of the week but never heard from anyone. We’re way cheaper than that (-: Unfortunately, my time isn't, so paying someone to help get this fixed would be worth it for me :-) This issue is a major distraction from the development work I actually need to do. It's something that an expert could probably fix in a few minutes but I've spent days on it. I do however appreciate your continued responses.

Thanks for all the help, specially from the Eskimo! I'm up and running properly now from the command line. I tried to make the process far more complicated than it actually needed to be. Question about notarization. After I have archived/codesigned via xcodebuild, I make a zip file which is uploaded to Apple by xcrun notarytool. During the notarization process, does that zip file or any of its contents get modified? In other words, do I have to wait for the notarization to finish or can I extract the application from the zip file and continue building my installer?

Hmm, how do I "staple the ticket" to my product? Presumably this is not something done by the notarisation process (if it was, then notarisation would not be a read-only process"

Also, one thing to watch out for is warnings and references that are due to Xcode plugins that are no longer "supported" I was getting bizarre warning messages mentioning a DVT framework which made no sense to me until I looked more closely and realized that they were due to some legacy plugins that were buried deep in an Xcode plugin folder (see below). Removing those plugins eliminated those warning messages. 2022-03-09 12:39:45.860 xcodebuild[46445:2278107] [MT] PluginLoading: Required plug-in compatibility UUID 7A3A18B7-4C08-46F0-A96A-AB686D315DF0 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/XBookmark.xcplugin' not present in DVTPlugInCompatibilityUUIDs 2022-03-09 12:39:45.861 xcodebuild[46445:2278107] [MT] PluginLoading: Required plug-in compatibility UUID 7A3A18B7-4C08-46F0-A96A-AB686D315DF0 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/Alcatraz.xcplugin' not present in DVTPlugInCompatibilityUUIDs

OK - so somehow that URL wasn't working for a while, just returning that rate limited exceeded method and trying again a few hours later actually gave me real explanations. Phew