ZXPSignCmd sign process is broken (segmentation fault)

Some is doing something, because apple timestamp no longer works, failing this time with a different error:

```

libc++abi: terminating due to uncaught exception of type boost::filesystem::filesystem_error: boost::filesystem::copy_file: File exists: "/tmp/zxpsignaOXSxzWIDPHbj6r0/tmp.zxp",

```

@Justin Taylor-Hyper Brew indeed on Windows ZXPSignCmd doesn't work!

Here is an update on the working solutions, based on my tests.

Working timestamps:

• http://timestamp.apple.com/ts01
• http://tss.accv.es:8318/tsa

Windows solution:

• https://github.com/JuMouren/SignAndPackage
  You will need to install Java, replace certum timestamp in .bat file with any of 2 above.

SignAndPackage worked with both timestamp.apple.com and tss.accv.es timestamps on Windows, so it seems that option B is correct.

B: Something is patched in ZXPSignCmd 4.1.2 to allow this, but since there was never a 4.1.2 version published for Windows, we're stuck with a bug on 4.1.1

By  @Justin Taylor-Hyper Brew

+1 waiting for a windows solution

Yes, the failures with DigiCert are the most concerning issue here. I'm just suggesting that using Apple is not really a fix due to Windows not trusting that root certificate. Even if you sign on a Mac, I'm not sure that Adobe will trust that timestamp on Windows. Then again, Adobe seems to trust self-signed certificates if you install a panel manually so maybe they don't care about the timestamp's root certificate, outside of ZXPSignCmd.
Hopefully signing with DigiCert will work again soon.

That may be part of the issue, but there must be more involed since other TSAs besides DigiCert used to work and now none of them work except Apple on Apple.

I believe the Apple timestamps are failing on Windows because the OS doesn't trust Apple's root certificate.

Did some more testing and http://timestamp.apple.com/ts01 worked for us on macOS, thanks to @Ivan Stepanov. All other timestamp servers resulted in either seg faults or "Error - cannot contact the chosen TSA". Adobe should open source this tool ASAP.

Great find @Ivan Stepanov, I'm glad that we have a working soluion for MacOS!

Unfortunately after testing on 14 different TSAs (from StackOverflow and and Davide), the problem still persists on Windows and on MacOS with any other non-apple TSA. (see full testing details below)

My guesses are either:

A: There is some speical access for Apple-to-Apple timestampping that allows the Apple TSA to work on Macs, but all others are broken

or

B: Something is patched in ZXPSignCmd 4.1.2 to allow this, but since there was never a 4.1.2 version published for Windows, we're stuck with a bug on 4.1.1

All ZXPSignCmd Versions (latest Win: 4.1.1, latest Mac: 4.1.2) 

It's great we have a solution for Mac, but lots of users, workflows, and build systems rely on Windows as well, so we need working solutions for both.

As @Softmatic GmbH and @Alex White have pointed out, it is possible to create a ZXP by omitting the TSA, however this comes with an expiration date, though "supposedly" far in the future, from the Adobe documentation in SigningTechNote.pdf sounds like it could break sooner without warning:

----------------------------------------------------------------------------------------------------------------------------------------------------

Full testing details on Mac and PCs:

Confirmed - switching from Digicert to the Apple tsa worked for us: http://timestamp.apple.com/ts01

Using the Apple tsa fixed this issue for us as well. 
Thanks @Ivan Stepanov for the helpful clue. 

Agreed that Adobe should provide an open source option for ZXPSignCmd. This is a critical part of the pipeline so when it breaks it would be good to understand why.