Timestamp Disservice
In the event that the timestamp server cannot be reached for whatever reason, codesign simply fails. This is probably a good idea, because if it’s important for signed code to also contain a timestamp, you wouldn’t want to accidentally ship a major release of your app without it. But because the timestamp server can be unavailable for a variety of reasons, some of them common, we need some simple solution for continuing with the the day-to-day building of our apps without ever being bothered by the pesky timestamp service issue.
Lucky for us, such a solution exists in the form of a codesign command-line flag: “–timestamp”. Ordinarily this flag is used to specify the URL of a timestamp server, if you choose to use one other than the Apple default. But a special value none indicates that timestamping of the signed code should be disabled altogether.
It’s not clear to me why the timestamp servers should be so unreliable.
2 Comments RSS · Twitter
You shouldn't say that "It’s not clear to me why the timestamp servers should be so unreliable." because there's an Apple engineer who claims that they are never unavailable and that the problem is on the developers' side. I guess this proves Apple engineers do not use their own products.
@someone do you have a link to that statement?
It would be nice to know how we can debug time server issues. With my current connection it fails maybe 5% of the time, but since Mavericks we need to individually sign each piece of executable code in an application bundle. This means signing my app with ‘--deep’ requires signing enough executable code to make the error rate closer to 100% (so I no longer sign my code using a timestamp).
