Notarization Stapling NSURLErrorDomain Code=-1005

Code Signing Notarization
filbercio OP
Created
Replies 3
Boosts 0
Views 332
Participants 2

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue.

All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating.

I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago:

error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>"
), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4}
CloudKit's response is inconsistent with expections: (null)

Answered by DTS Engineer in 913942022

This is almost certainly an issue with your local environment. As you can see from the log you posted, stapling fetches the ticket from a CloudKit database, accessed via HTTP requests. Error -1005 indicates that URLSession was able to open the connection to the server, and then it dropped [1]. It’s possible that the CloudKit servers could be having this problem but if they were it’s likely that there’d be a lot more noise about this, both here on DevForums and also from normal users.

I recommend that you retest this stuff in a different environment. For example, if you’re currently testing on a work Mac, try again on your home Mac, or vice versa. Remember that you don’t need credentials to staple, so running these tests is easy.

Keep in mind that it might not just be the network in play here. I occasionally see problems like this from folks who have… well… let’s just say… over-enthusiastic enterprise security software installed.

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

[1] I have a whole Q&A about that error: QA1941 Handling “The network connection was lost” Errors.

Replies  3
Boosts 0
Views  332
Participants  2
DTS Engineer OP
Apple
Recommended

This is almost certainly an issue with your local environment. As you can see from the log you posted, stapling fetches the ticket from a CloudKit database, accessed via HTTP requests. Error -1005 indicates that URLSession was able to open the connection to the server, and then it dropped [1]. It’s possible that the CloudKit servers could be having this problem but if they were it’s likely that there’d be a lot more noise about this, both here on DevForums and also from normal users.

I recommend that you retest this stuff in a different environment. For example, if you’re currently testing on a work Mac, try again on your home Mac, or vice versa. Remember that you don’t need credentials to staple, so running these tests is easy.

Keep in mind that it might not just be the network in play here. I occasionally see problems like this from folks who have… well… let’s just say… over-enthusiastic enterprise security software installed.

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

[1] I have a whole Q&A about that error: QA1941 Handling “The network connection was lost” Errors.
filbercio OP

Thanks for the reply Quinn:)

Unfortunately I can't try going from Work to Home, as my home Mac is my work Mac (and vice-versa). So instead this morning I first tried restarting my Google Fiber and UniFi equipmenent, hoping that it might help. But unfortunately I ran into the Stapling timeout again. The only thing that seems to help is when I Restart my M4 Studio. After a Restart, Stapling worked fine. I did the same thing (Restarted) after Stapling timed out on me last week, and it temporarily fixed the problem. It's pretty anecdotal I know. So... 🤷

DTS Engineer OP
Apple
Written by filbercio in 914138022

It's pretty anecdotal I know.

True, but it’s a place to start. Oh, and it’s also a pretty reasonable workaround.

One option is to set up a VM on your Mac and then, the next time you see this, start the VM and try stapling from there. If you configure the VM to use bridged networking then it’s a peer to your main Mac on the local network. So, if your VM works and your main Mac fails, it’s very likely that the problem is local to your main Mac, that is, you’ve ruled out the network as the problem.

And if that’s the case then you can start debugging locally. Given that stapler is using CloudKit which is using URLSession, you can install the CFNetwork and Network Diagnostics diagnostics debug profile and see what shows up in the system log.

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