I don’t think this is an apple issue that you are encountering. We have had no issues from any of our networks or build machines since the original issue was resolved over a year ago. As Quinn mentioned, this appears to be a networking issue on your own network. I would suggest reaching out to your IT and security teams and see what changes they made on July 18th to determine if there may be new firewall rules that they recently put into place that are preventing access to the time stamp service. I know that many organizations will try to “lock down” their networks - particularly those networks that have access to source code - and this can cause problems with the time stamping and notarization services. In fact, just a few months ago, my own organization did a firewall rule review, updated some rules, and broke our access for timestamping and notarization. we had to re-request our firewall exemptions to our internal security team to allow the signing and notarization to work again. But the most important thing is, this is doesn’t look like an apple issue, and there is nothing that can be done from apples side to resolve it. I would suggest working with your company help desk, IT, and/or security teams to resolve this issue. The document at https://support.apple.com/en-us/HT210060 is likely a good place to start for what endpoints need to be available from your network (there may be additional endpoints - for example, I don’t see timestamp.apple.com on that list - we just ensure that we can access everything on 17.0.0.0/8 and have had no problems). If, after working and ruling out your own organizations networking issues, there continues to be a problem, I suggest you open a developer support incident with apple - this thread is for a completely separate issue from over a year ago that has been resolved - and there are MANY people on this thread who do not need to be getting notifications of your corporate firewall issues.

It isn't needed - we are just seeing on some customer machines that signals are not being delivered to our application (we send SIGUSR* signals to communicate between some troubleshooting scripts we have and our application). In some cases, those signals are not getting delivered to our application, and we were wondering if it might be related to something that they are doing with their MDM configuration.

I have logged a bug as FB9815906 with an example project which shows this behavior.

To note - this happens with both the appstore version of xcode as well as the version downloaded from developer.apple.com. The only known workaround now is to install version 13.1

Rolling back to Xcode 13.1 fixes the issue. The issue exists in both Xcode 13.2 and 13.2.1

I added the wrong FB ID - the correct one is FB9668079. I think I will still log the DTS incident and continue discussion there (sharing code snippets as needed, etc).

I get this same warning whenever I try to build an app (a macOS app) using xcodebuild when I have a locked iOS device connected to my machine. Unlocking the device suppresses the warning in xcodebuild.

It actually works without doing the export as well (if you just point to the original plist in ~/Library)...in my original post I listed PlistBuddy as an approach - and it will be sufficient for me as a workaround. I hadn't logged a bug, since it seemed to be working as designed (using data(using:allowLossyConversion:)) and for my particular case, I need something that will work in older versions of the OS as well. I have now logged it as FB9160695. Thank you for the pointers and the guidance!

Thank you - that makes sense with what I am seeing. The workflow is to be able to store/recover string values from within a system of shell scripts. Is there some shell command that would allow us to unescape the values?

Some additional information from my setup: altool is from Xcode 12 as well. I do not authenticate with the notary using an api key. It ended up succeeding after 4 tries - and then it failed again on the 5th and succeeded in the 6th. So - it seems to be random when it occurs. Most of the times, it failed to find metadata.xml - but one of the times it failed to find the zip file I was notarizing. It doesn’t appear to be a network issue - as (in the log) it looks like it succeeded: [2021-04-12 21:07:45 MDT] main INFO: Package upload progress: 100.00% completed [2021-04-12 21:07:45 MDT] main INFO:     File: metadata.xml 541/541, 100.00% completed [2021-04-12 21:07:45 MDT] main INFO:     File: binaries-macOS.zip 25085345/25085345, 100.00% completed [2021-04-12 21:07:45 MDT] main INFO: Waiting on reservation commit(s) to finish. [2021-04-12 21:07:45 MDT] pool-9-thread-1 INFO: All reservation commit(s) finished. Later in this same log is where it claims it cannot find binaries-macOS.zip (the file I was trying to notarize): [2021-04-12 21:07:46 MDT] main DBG-X: Apple's web service operation return value: [2021-04-12 21:07:46 MDT] main DBG-X:  parameter Errors = [Unable to find requested file(s): binaries-macOS.zip (1057)] There is a possibility this might be device-related - I have two build servers, and two of the six failures happened on one of the servers, and the two successes happened on the other server. Unfortunately, I don’t have logs from the first two failures to see which build server they were on. I rebuilt the build server that failed twice - but haven’t had a chance to try submitting again using it. This also might be a red herring - since it appears the files were fully sent to the notarization service...so I can’t imagine how it would be device-related.

I also am seeing this same error - also on Catalina (but I don't have access to a Big Sur build machine to test on) Also using xcrun altool --notarize-app

It appears that switching to --transport HTTPS from --transport DAV may address the issue. I don't know what we lose by making that switch. We have been using DAV on suggestion from Apple Support for a few years with no issue, given our firewall restrictions we have in place on our network, and I don't know if switching to HTTPS will have any negative effect on our ability to notarize.

Also - for completeness of what I'm doing, I'm notarizing from command line using: xcrun altool -u "${APPLE_USERNAME}" \p "${ALTOOL_PASSWORD:-"@keychain:${APPSTORE_KEYSTORE_ITEM}"}" \ --asc-provider "${APPSTORE_ASC_PROVIDER}" \-notarize-app --transport DAV \ --primary-bundle-id "${APPSTORE_BUNDLE_ID}" \f "${PATH_TO_FILE}"

This is on a build server that has worked for years - nothing has changed on it or on its network. I sign (as a part of my build) 5 different binaries. A different one fails each time. I was able to take a PCAP from that machine during its build process - and it shows three successful time stamping as and a fourth request (with no corresponding response).

I am seeing this starting this evening - did something happen again?