codesign/produtsign 3rd paty TSAs

Hi ,
I've couple of questions relate to timestamp server used for codesign and productsign commands.
  1. Can I use any timestamp server with codesign command? If yes, can you please share list of trusted TSAs? Also, will notarization succeed if I use non-apple timestamp server? codesign -fs ${identity} TestApp.app --timestamp=${timestampServer}

  2. How do I specify a timestamp server in productsign command?

Answered by DTS Engineer in 659823022

Basically, I'm exploring the option of signing artifacts with other
TSA in case Apple's TSA is down.

My advice here is very simple: Use Apple’s timestamp server. Anything else puts you way off the beaten path and the problems you encounter will far outweigh any benefits you get.

Share and Enjoy

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

Can I use any timestamp server with codesign command?

Apparently

If yes, can you please share list of trusted TSAs?

You mean other than Apple? Trusted by whom? The codesign command does support a timestamp server parameter. If you trust the server, then you can supply a parameter. I have no idea if it works or not.

Also, will notarization succeed if I use non-apple timestamp server?

Utterly no clue. Given what I've seen regarding Notarization problems, this seems like a high-risk approach. Notarization is drop-dead, fall-of-a-log, Oh My God This is Easy! Yet some people insist on trying new and unusual ways to build code and attempt to notarize it. Each new failure is more comical and bizarre than the last.

If you sincerely think it would be a good idea to use a custom timestamp server and to attempt to notarize software with it, why don't you just try it and see if it works? What's the worst that could happen? Your download displays a big "cannot check for malware" warning? Some minor operating system update causes your app to stop working? Your app stops working on its own on some random date in the future and no one know why? Your customer band together and file a class-action lawsuit?

How do I specify a timestamp server in productsign command?

I see no timestamp server option in the productsign command.
Thanks Etresoft for quick response.

You mean other than Apple? Trusted by whom? The codesign command does
support a timestamp server parameter. If you trust the server, then you
can supply a parameter. I have no idea if it works or not.

Yes, I mean trusted by Apple. What I have seen with experimentation is that when I sign with some TSA other than that of Apple's then Authority=(unavailable) is shown in signature, that’s the reason I'm not sure it will work. Basically, I'm exploring the option of signing artifacts with other TSA in case Apple's TSA is down. Please find the output of codesign verify command on artifact signed with and without Apple's TSA.
Also, can there be any unforeseen issues after signing?


Some minor operating system update causes your app to stop working? Your
app stops working on its own on some random date in the future and no
one know why? Your customer band together and file a class-action
lawsuit?

This is exactly what I am worried about, the unforeseen issues. Basically if there is slight possibility of any of the above issues then it becomes no-go for me but then it makes me wonder why is there an option to specify TSA in codesign command.

I see no timestamp server option in the productsign command.
productsign command man page only describes --timestamp or --timestamp=none options, does that mean we cannot pass custom TSA?


Code Block
➜ TestAppfe336ce1-1a24-4ef7-9540-5b2e67d5ef95 codesign -fs C33F74F52338E990231916C20C3D57E09E8A1D38 TestApp.app --timestamp=http://timestamp.apple.com/ts01
TestApp.app: replacing existing signature
➜ TestAppfe336ce1-1a24-4ef7-9540-5b2e67d5ef95 codesign --verify --deep --verbose=4 --display TestApp.app
Executable=${pathToApp}/TestApp.app/Contents/MacOS/TestApp
Identifier=com.zyx.test.TestApp
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=636 flags=0x0(none) hashes=14+3 location=embedded
VersionPlatform=1
VersionMin=659200
VersionSDK=721152
Hash type=sha256 size=32
CandidateCDHash sha256=a17687c5eb3457a758d758ef9a6a2e100676ecb7
CandidateCDHashFull sha256=a17687c5eb3457a758d758ef9a6a2e100676ecb7b6a384c0fc870a7591b9bd38
Hash choices=sha256
CMSDigest=a17687c5eb3457a758d758ef9a6a2e100676ecb7b6a384c0fc870a7591b9bd38
CMSDigestType=2
Page size=4096
CDHash=a17687c5eb3457a758d758ef9a6a2e100676ecb7
Signature size=9053
Authority=Apple Development: abc@zyx.com (${TeamID})
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Timestamp=Jan 31, 2021 at 10:21:03 PM
Info.plist entries=21
TeamIdentifier=78LUKHP485
Sealed Resources version=2 rules=13 files=4
Internal requirements count=1 size=192
--------------------------------------------------------------------------------------------------------------------
➜ TestAppfe336ce1-1a24-4ef7-9540-5b2e67d5ef95 codesign -fs C33F74F52338E990231916C20C3D57E09E8A1D38 TestApp.app --timestamp=http://timestamp.entrust.net/TSS/RFC3161sha2TS
TestApp.app: replacing existing signature
➜ TestAppfe336ce1-1a24-4ef7-9540-5b2e67d5ef95 codesign --verify --deep --verbose=4 --display TestApp.app
Executable=${pathToApp}/TestAppfe336ce1-1a24-4ef7-9540-5b2e67d5ef95/TestApp.app/Contents/MacOS/TestApp
Identifier=com.zyx.test.TestApp
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=636 flags=0x0(none) hashes=14+3 location=embedded
VersionPlatform=1
VersionMin=659200
VersionSDK=721152
Hash type=sha256 size=32
CandidateCDHash sha256=a17687c5eb3457a758d758ef9a6a2e100676ecb7
CandidateCDHashFull sha256=a17687c5eb3457a758d758ef9a6a2e100676ecb7b6a384c0fc870a7591b9bd38
Hash choices=sha256
CMSDigest=a17687c5eb3457a758d758ef9a6a2e100676ecb7b6a384c0fc870a7591b9bd38
CMSDigestType=2
Page size=4096
CDHash=a17687c5eb3457a758d758ef9a6a2e100676ecb7
Signature size=10051
Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=78LUKHP485
Sealed Resources version=2 rules=13 files=4
Internal requirements count=1 size=192


Basically, I'm exploring the option of signing artifacts with other
TSA in case Apple's TSA is down.

My advice here is very simple: Use Apple’s timestamp server. Anything else puts you way off the beaten path and the problems you encounter will far outweigh any benefits you get.

Share and Enjoy

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

Yes, I mean trusted by Apple. What I have seen with experimentation is that when I sign with some TSA other than that of Apple's then Authority=(unavailable) is shown in signature, that’s the reason I'm not sure it will work. Basically, I'm exploring the option of signing artifacts with other TSA in case Apple's TSA is down.

I doubt that Apple, or any reasonable company or organization, would trust anyone other than themselves.

I have seen people try to justify a custom timestamp based on the fear that Apple's server goes down. But Apple is one of the biggest companies in the world, would you be able to find some other service that is more reliable? And what is the risk of a failure on Apple's part? And what is the cost of failure on Apple's part? By this I mean, how likely is Apple's server to go down and how long would it stay down?

Also, can there be any unforeseen issues after signing?

This is exactly what I am worried about, the unforeseen issues. Basically if there is slight possibility of any of the above issues then it becomes no-go for me but then it makes me wonder why is there an option to specify TSA in codesign command. 

There is always a possibility of failure. In fact, there is always an absolute guarantee of failure. It is only a question of when. Are you going to find some other service that has a lower possibility of failure than Apple? And what additional risks or costs are you willing to spend for that (false) guarantee?

As I understand it, the reason for this option is to allow signed software in an environment that does not have internet access. Such facilities typically have other, often physical, security mechanisms in place. In theory, you might be able to use a local timeserver in such an environment. But in any environment that has internet access, I can't think of any rational reason not to use Apple's servers.

Think of it this way. If you do something funky and it breaks, that's on you. You bear sole responsibility for any and all damages. No one will remember or notice if your software was functional during some Apple outage. If there were a widespread Apple outage, some other cascading failure would likely prevent your software from working anyway.

But if you accept the Apple defaults and it breaks, that's on Apple. No one will blame your company or software. A few haters might say that you shouldn't have trusted Apple, but haters should be ignored. You will never be able to satisfy them no matter what you do.


codesign/produtsign 3rd paty TSAs
 
 
Q