I've got an old Xcode project, that when freshly checked out, hasFile->Project Settings ... Advanced ... Build Location set to "Legacy"When I set the value to "Default", all is good, and I can see that inMyProject.xcodeproj/project.xcworkspace/xcuserdata/MyUsername.xcuserdatad/WorkspaceSettings.xcsettings,the "BuildLocationStyle" entry has been set to "UseAppPreferences"However, I would like other users doing a fresh checkout to get the"Default" setting instead of the "Legacy" one.Is there some way to change this for everyone, or alternatively, whatis it about the project that causes Xcode to pick "Legacy" initially? cheers, m.
Post
Replies
Boosts
Views
Activity
We are seeing Apple code signing failures when retrieving secure timestamps from several locations (but not all locations) in Australia. This has been happening since Friday July 17th 2020
We're seeing this issue with multiple apps and certificates from different organisations
During codesigning, in some configurations, a request is sent to an Apple timestamp authority server to authenticate the time of signing. This is failing for (some of) us. tcpdump and wireshark revealed that for my home network, the server is timestamp-reno01.apple.com (17.179.249.1). Requests are sent via http over port 80, but traffic is TLS encrypted (https://developer.apple.com/forums/thread/96154 has some interesting details).
In Wireshark, I can see the SYN being sent, but no ACK is ever received, and after some tcp retries, signing fails. This only happens during code signing.
I can telnet directly to port 80 on 17.179.249.1), and get a connection, which makes no real sense.
Out of six locations in Australia (5 home offices, 1 corporate office), four are affected. The problem does not appear to be specific to any ISP. We see failures with Telstra and Internode, but also successes on Telstra and Optus
If we connect to the company VPN in the US, everything works as expected.
Our developers in Europe and the US do not seem to be affected.
Traceroutes from my working and non-working networks to 17.179.249.1 appear to show very similar routes through Telstra's infrastructure to Apple's 17.x.x.x IP block.
I know that normally the answer to this problem is "check your firewall", but we're seeing this in so many locations, all of which started to fail simultaneously (all of which have been fine for literally years) and across multiple ISP's, that we don't think the problem is with our local setups.
Filed as FB8089242