Is anyone else having trouble with notarization in the past few days?

Question

Created Dec ’21

Replies 7

Boosts 0

Views 1.4k

Participants 2

This started happening this Thursday, and hasn't seemed to have gotten better since; every time I try to notarize my app, it fails.

The app is signed:

$ codesign -vv Pacifist.app
Pacifist.app: valid on disk
Pacifist.app: satisfies its Designated Requirement

$ codesign -dvv Pacifist.app
Executable=##redacted##/Pacifist.app/Contents/MacOS/Pacifist
Identifier=com.charlessoft.pacifist
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=12004 flags=0x10000(runtime) hashes=364+7 location=embedded
Signature size=9009
Authority=Developer ID Application: Charles Srstka (HRLUCP7QP4)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 11, 2021 at 12:36:01 PM
Info.plist entries=39
TeamIdentifier=HRLUCP7QP4
Runtime Version=12.0.0
Sealed Resources version=2 rules=13 files=428
Internal requirements count=1 size=216

$ spctl -a -v --raw Pacifist.app  
Pacifist.app: accepted
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>assessment:authority</key>
	<dict>
		<key>assessment:authority:flags</key>
		<integer>2</integer>
		<key>assessment:authority:row</key>
		<integer>6</integer>
		<key>assessment:authority:source</key>
		<string>Developer ID</string>
	</dict>
	<key>assessment:remote</key>
	<true/>
	<key>assessment:verdict</key>
	<true/>
</dict>
</plist>

Looks good, right?

But since Thursday, notarytool isn't having it:

$ xcrun notarytool submit Pacifist.zip --apple-id ###redacted### --team-id HRLUCP7QP4 --wait 
Conducting pre-submission checks for Pacifist.zip and initiating connection to the Apple notary service...
Password for ###redacted###: 
Submission ID received
  id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca
Successfully uploaded file77.6 MB of 77.6 MB)   
  id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca
  path: ###redacted###/Pacifist.zip
Waiting for processing to complete.
Current status: Invalid.............
Processing complete
  id: eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca
  status: Invalid

Trying to export from Xcode's "Organizer" window actually crashes Xcode. I can provide the crash log upon request, although since I've clicked the "Send to Apple" button each time, this should be available for Apple engineers to look at.

What sometimes works is to use xcrun xcodebuild -exportArchive. However, this is not 100%, and so far all the times that that has worked have been when I've run the tool by hand; for some reason, running as a post-archive action fails every time (I don't know if this is just a weird coincidence or not).

The status page for Apple's services seems to be all green... What is going on? Is anyone else running into this same issue?

Boost

Answer 1

CharlesS OP

Dec ’21

I should add the specific error that the notary service is complaining about:

$ xcrun notarytool log eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca --apple-id ##redacted# --team-id HRLUCP7QP4
Password for ##redacted##: 
{
  "logFormatVersion": 1,
  "jobId": "eaa1e96e-38d0-4d6d-ad0f-bc58564b7eca",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "Pacifist.zip",
  "uploadDate": "2021-12-11T17:52:07.189Z",
  "sha256": "c589ce3b11429ebfc3f343c77053df3416438c11bad690f0ca1307aee585529e",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "Pacifist.zip/Pacifist.app/Contents/MacOS/Pacifist",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "Pacifist.zip/Pacifist.app/Contents/MacOS/Pacifist",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "arm64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "Pacifist.zip/Pacifist.app/Contents/XPCServices/PacifistXPCService.xpc/Contents/MacOS/PacifistXPCService",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "Pacifist.zip/Pacifist.app/Contents/XPCServices/PacifistXPCService.xpc/Contents/MacOS/PacifistXPCService",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "arm64"
    },
( ... repeat for every other binary in the app ... )

However, as we've seen above, both codesign -vv and spctl seem to think the signature is fine 🤷‍♂️

0

Answer 2

DTS Engineer OP

Apple

Dec ’21

I don’t think this is a problem with the notary service; if it were, it’s likely my hair would be on fire!

Also, I just run a simple test here and it seems to be working just fine.

Trying to export from Xcode's "Organizer" window actually crashes Xcode.

Well, that’s not good.

I can provide the crash log upon request, although since I've clicked the "Send to Apple" button each time, this should be available for Apple engineers to look at.

I’m sure that someone, somewhere at Apple will have access to this. However, there’s no easy way for me to map your details to such reports (data privacy and all that). If you can post that crash report here, that’d be grand.

See Posting a Crash Report for info on how to do that.

What sometimes works is to use xcrun xcodebuild -exportArchive.

When that fails, how does it fail? Crashing as well? Or something else?

What does the following report for the app that you submit to the notary service?

% codesign -v -vvv --deep Pacifist.app

ps Love your app! Ironically, it’s an important tool in my toolbox when debugging notarisation issues for third-party developers (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

CharlesS OP

Dec ’21

I’m sure that someone, somewhere at Apple will have access to this.
However, there’s no easy way for me to map your details to such reports (data privacy and all that). If you can post that crash report here, that’d be grand.

Sure thing; I've e-mailed the crash report privately to your e-mail address so I don't have to go through and redact any private details of my machine from it. :-)

What sometimes works is to use xcrun xcodebuild -exportArchive.

When that fails, how does it fail? Crashing as well? Or something else?

Frustratingly, I can't seem to reproduce this with xcodebuild -exportArchive today. In the past, a lot of the times this one has failed have been when running as part of my post-archive script, which famously doesn't show a lot of the output. So I'm not 100% on what was going on there, although if I had to hazard a guess, I'd guess that the xcodebuild tool is probably crashing in the same way that the GUI app does. If I can get this one to occur again, I'll update with more details.

What does the following report for the app that you submit to the notary service?

% codesign -v -vvv --deep Pacifist.app

$ codesign -v -vvv --deep Pacifist.app
( ... bunch of "prepared:" and "validated:" lines that were causing this post to be over the character limit ... )
Pacifist.app: valid on disk
Pacifist.app: satisfies its Designated Requirement

The odd thing about this particular build is that this very build passed the notarization process (via xcodebuild -exportArchive) earlier today. Fails every time with notarytool, though, and crashes the GUI if I try it there.

ps Love your app! Ironically, it’s an important tool in my toolbox when debugging notarisation issues for third-party developers (-:

:-)

0

Answer 4

DTS Engineer OP

Apple

Dec ’21

I've e-mailed the crash report privately

Thanks.

And, yeah, that’s weird. Xcode is throwing a language exception which is crashing the app. Some internal tools suggest that this crash is super rare. If I had to guess I’d say that you’re the only person hitting it (lucky you!). You should definitely file a bug about this, including the crash report and the Xcode archive that triggers it.

Please post your bug number, just for the record.

On the notarytool side of things, well, sheesh, I’ve no idea. The notarisation log suggests you have severe code signing issues and those would usually be revealed by the codesign command.

To investigate further I need to look at your stuff in detail, and that’s more than I can do in the context of DevForums. Please open a DTS tech support incident and we can pick things up in that context.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 5

CharlesS OP

Dec ’21

Sorry for taking so long to respond; in the meantime, Xcode 13.2 came out, and I wanted to have time to test it properly to see if it might fix the problem I was complaining about (unfortunately, it did not).

I actually created a DTS incident a few days before making this thread; the number is 101572491467. I created the thread because I wasn't seeing a lot of traction there.

I have a new Xcode crash report that I can also e-mail to you privately, if desired; else, it should now be attached to the referenced DTS incident.

0

Answer 6

DTS Engineer OP

Apple

Dec ’21

I actually created a DTS incident a few days before making this thread; the number is 101572491467.

That’s not a DTS incident number; our numbers look like 7nnnnnnnn. I suspect you’ve connection with Developer Program Support, who are unlikely to be able to help in this case.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 7

CharlesS OP

Dec ’21

To me, this seems like a tooling issue, rather than a code-level support issue, but I suppose that my code-level incidents for this year will expire soon anyway, so may as well use them.

Here is the number of a code-level DTS incident that I just opened:

789609043

0