Open thebeeland opened 7 years ago
Working with Jeff on this. Would love to get any input/info from the Adobe team. Thanks!
The signatures.xml file contains all of your panel file paths - is it possible that there is a character in one of your file names that is causing an XML issue, for example an "&" (ampersand)? Try checking your signatures.xml file with an XML validator like Validrome (http://validome.org/xml/validate/, using the "Well-Formedness only" setting).
This wouldn't explain why it's working properly in macOS, but it's worth checking.
Hey @stompychump thanks for the info! I just ran the signatures.xml
that's generated on OS X through that validation and it says the document is well-formed. No .xml
file is generated on windows because it fails immediately. :(
It's worth noting that a ZXPSignCmd.exe -verify <zxp> -certinfo
on Windows fails on a .zxp successfully signed on OS X with the following:
Error - Invalid Signature element encountered.
This same verify command on OS X comes back successful, and we have no issues installing/using the extension in Photoshop. It seems to me like something is wonky with the XML parser used in the Windows build.
Are you running this in Windows 7? In my experience, ZXPSignCmd v4.0.7 is missing several DLL dependencies in W7, which are not documented and do not generate any error messages. I could not get ZXPSignCmd to work properly until I added the following DLLs to the same folder:
Perhaps you are encountering similar DLL issues.
@thebeeland can you please share your ZXP extension which is signed on OS X but failing verification on win? It will help me to debug the signature file.
@akshitSinghal1989 We go live with this PS integration on Wednesday (Feb 1). I can link you guys to the zxp after that, as the github repo will go public at that point.
This is occurring on Windows 7, and I should have pointed that out initially. I plan to move over to Windows 10 soon'ish, so if the problem with ZXPSignCmd is resolved afterwards then I'll be good to go. In the meantime, when I get a minute I can fire up a Windows 10 VM and confirm that it works there with our signed extension.
Thanks for the input @stompychump and assistance @akshitSinghal1989. Much appreciated!
@thebeeland sounds good to me.
@akshitSinghal1989, our repo is public now. The .zxp
file is located here: https://github.com/shotgunsoftware/tk-photoshopcc/blob/master/com.sg.basic.ps.zxp
I downloaded your ZXP and it verifies correctly on my Windows 7 system using ZXPSignCmd 4.0.7. I also re-signed your extension (after unzipping the ZXP and deleting the META-INF folder and mimetype file), and that also works correctly. So it appears that the issue is something on your system, rather than in the extension itself.
Are you able to sign other extensions, for example one of the Adobe samples in this repo?
@josh-t Thanks for sharing the extension. As @stompychump mentioned, it is working fine on my machine as well. Could you please check the same on any other win 7 machine in your workgroup with a fresh downloaded ZXPSignCmd 4.0.7?
I'm having this same problem on a Mac.
Hi @justinputney, Did you run into the same issue on a Mac while working with the extension posted by @josh-t ? or did you try signing your own extension and run into the same issue?
I was working on my own files and was able to resolve the issue by changing my process.
@justinputney could you share with us what the cause was and how you solved the issue? Much appreciated!
I was try to apply the command to a .zxp rather than a folder. The ZXP seem to be updated and I got a "success" result from the -sign command, but it wasn't verifying properly.
I'm running into this issue now. I'm on a Windows 10 system, but as far as I can tell, no signatures.xml
file exists. Is it supposed to? Where is it supposed to be? What are its contents supposed to be? I'm really confused by this error.
I was able to create the .p12
file without issue using -selfSignedCert
, but no signatures.xml
file was also created, so I cannot create the .zxp
file. What am I supposed to do?
I uploaded a new version of ZXP Sign recently... but if that's the version that's giving you trouble, and there are no answers here, you could try using this third-party Self-Signing panel tool...
Thanks for responding, @ErinFinnegan, but I'm afraid your suggestions are not working.
The version you linked to (4.1.1) gave me the same output:
PS C:\Users\christopher.mcgee\dev\Projects> .\ZXPSignCmd.exe -selfSignedCert US KY "Sky Unlimited Inc." "Chris McGee" password sky-open-template.p12
Self-signed certificate generated successfully
PS C:\Users\christopher.mcgee\dev\Projects> .\ZXPSignCmd.exe -sign .\sky-open-template\current .\sky-open-template.zxp .\sky-open-template.p12 password -tsa http://timestamp.comodoca.com/rfc3161
Error - Failed to parse signatures.xml. Check for valid XML format.
PS C:\Users\christopher.mcgee\dev\Projects>
The second link is just the documentation that I've been following all along. I see no answers there for this issue.
Finally, the third-party tool is just a wrapper of sorts to automate ZXPSignCmd.exe
. If ZXPSignCmd.exe
won't even run manually, then I shouldn't bother with automated tools until it does. Just for kicks, I tried using it anyway. Here's the result:
PS C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\extensions\com.skyunlimitedinc.open-template> yarn run sign
yarn run v1.19.1
$ node ./src/utils/dev/npmCommands.js sign
CEP 😅 Didn't mean to do that? Use npm run help to see a full list of commands
CEP 🤘 Signing Open-Template1.0.0!
Be sure to run npm run register prior to this command.
You can add any valid regex or phrases to ./src/utils/dev/.certignore to exclude them from staging.
? Password for certificate (hello-world)
? Password for certificate hello-world
? Create a ZIP aswell? Yes
✔ Staging complete.
â š Running ZXPSignCmd for you...ZXPSignCmd -selfSignedCert US KY Sky-Unlimited,-Inc. Chris-McGee hello-world ./com.skyunlimitedinc.open-template/archive/temp1.p12
(node:36568) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, chmod 'C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\Open-Template1.0.0-tmp\.git\objects\07\7925703b1563e28196e4a8509d49e386e5a473'
(node:36568) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:36568) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
â ¦ Running ZXPSignCmd for you...ZXPSignCmd -sign ./Open-Template1.0.0-tmp ./com.skyunlimitedinc.open-template/archive/Open-Template1.0.0.zxp ./com.skyunlimitedinc.open-template/archive/temp1.p12 hello-world -tsa http://time.certum.pl
â ³ Running ZXPSignCmd for you...ZXPSignCmd -verify ./com.skyunlimitedinc.open-template/archive/Open-Template1.0.0.zxp -certinfo
Error - Arguments are invalid. Process failed.
✔ Signing is complete.
(node:36568) UnhandledPromiseRejectionWarning: Error: EPERM: operation not permitted, lstat './com.skyunlimitedinc.open-template/archive/temp1.p12'
at Object.lstatSync (fs.js:906:3)
at Object.lstatSync (C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\extensions\com.skyunlimitedinc.open-template\node_modules\graceful-fs\polyfills.js:308:16)
at Object.rimrafSync [as removeSync] (C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\extensions\com.skyunlimitedinc.open-template\node_modules\fs-extra\lib\remove\rimraf.js:237:18)
at C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\extensions\com.skyunlimitedinc.open-template\src\utils\dev\npmCommands.js:212:19
at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:36568) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
Done in 10.73s.
PS C:\Users\christopher.mcgee\AppData\Roaming\Adobe\CEP\extensions\com.skyunlimitedinc.open-template>
Am I seriously just not able to create CEP extensions on Windows?
Hi Chris, do you have a .git folder in there? Can you confirm the wrapper is properly staging (removing hidden folders like .git and node_modules) then signing?
Hi Chris, do you have a .git folder in there? Can you confirm the wrapper is properly staging (removing hidden folders like .git and node_modules) then signing?
Hi Inventsable. I can confirm that there is a src/utils/dev/.certignore
file that the wrapper makes which has the contents:
node_modules
archive
^(\.git)
I can also confirm that ZXPSignCmd.exe
still complains about failing to parse signatures.xml
even when all unnecessary folders are removed from the staging folder (.git
, .idea
, .vscode
, node_modules
, etc.)
Okay. Just to confirm, you do have a .git folder inside your repo though? Can you share if it's a public repo? That error being thrown during the wrapper staging might prevent it from removing these.
When you first tried manually signing, did you remove your .git and node_modules folders prior to running the commands?
Certainly, Inventsable, I can share it. I've made the repo public:
https://github.com/SturmB/sky-open-template/tree/restructure
I'm on the restructure
branch since master
was made back when we had Mac computers here.
When I first tried manually signing, no, there was still a .git
folder (as well as .idea
and .vscode
), but no node_modules
folder. I used Deployer to stage it for me. Since then, however, as noted in my previous comment, I have removed said folders from the staging area, but ZXPSignCmd.exe
still gives me the same error.
Things are getting worse.
The signing script (wrapper) creates a ./archive/temp1.p12
file that cannot be deleted, no matter what I try. No amount of admin privileges are allowing me to delete it.
I pull from the repo to a new folder, run yarn install
and yarn run register
, then yarn run sign
, but it still keeps erroring out one way or another.
In one instance, it keeps complaining about UnhandledPromiseRejectionWarning
.
In another instance, it'll complain about the timestamp returned from the chosen TSA not being able to be verified. Yet it will claim that the .zxp
file was generated in ./archive
, but this is not the case.
All of this, yet running the same sequence of steps (install, register, sign) on a fresh copy of the Self-Signing Panel repo works fine.
I'm getting so frustrated and I'm running out of time to get this to work.
Have you tried -tsa http://timestamp.digicert.com
as a timestamp site yet? I was getting errors before I switched to that one...
I'll try this myself in the next few days
Have you tried
-tsa http://timestamp.digicert.com
as a timestamp site yet? I was getting errors before I switched to that one...
Thank you for that. I've tried others but they all failed:
http://time.certum.pl
- Our company hardware firewall blocks non-US domainshttps://timestamp.geotrust.com/tsa
- Error - cannot contact the chosen TSAhttp://timestamp.comodoca.com/rfc3161
- (Don't remember the message, but it failed)Pulling a fresh copy of my repo and using that DigiCert URL for the timestamp seems to be the ticket. @MaxJohnson, you are a lifesaver!
Great! Just an fyi, I rebuilt these commands as an npm package for my Bombino panel generator, here:
https://github.com/Inventsable/bombino-commands
The sign function is the only one I didn't revamp, but I could adjust the register command to allow custom timestamps. If you want to alter it manually, it's at the end of this string:
https://github.com/Inventsable/bombino-commands/blob/master/lib/sign.js#L208
I've forked your repo, @Inventsable, so that I can customize it for myself. Also to see if I can alter it to run from within WSL. And if we go any further with this conversation, we should probably move it elsewhere since we've now strayed from the original topic. 🙂
No problem, feel free to post issues. Just wanted to point out you forked the old version, new version is an NPM package and has standalone bin files per command.
Have you tried
-tsa http://timestamp.digicert.com
as a timestamp site yet? I was getting errors before I switched to that one...Thank you for that. I've tried others but they all failed:
http://time.certum.pl
- Our company hardware firewall blocks non-US domainshttps://timestamp.geotrust.com/tsa
- Error - cannot contact the chosen TSAhttp://timestamp.comodoca.com/rfc3161
- (Don't remember the message, but it failed)Pulling a fresh copy of my repo and using that DigiCert URL for the timestamp seems to be the ticket. @MaxJohnson, you are a lifesaver!
Thank goodness it was a 'simple' albeit obscure fix!
I did let the ZXP team know about this thread. Please let us know the solution and if you get it fixed, @SturmB.
@ErinFinnegan Awesome, thanks!
The solution, as mentioned in my previous comment, was to use the correct URL for the -tsa
option. Why, on Earth, using a wrong one would cause that initial pop up error Failed to parse signatures.xml
is beyond my understanding. Or perhaps there was more going on beyond that at the time; I don't know.
In any case, because our company blocks all .pl
TLDs in our hardware firewall, and because the other two URLs just weren't responding (or were returning malformed responses?), I could not use them. It was almost a Hail Mary to try using the DigiCert URL instead and I got lucky that it actually worked!
Now, whether or not this fix would help the OP (or anyone else, for that matter) with the same signatures.xml
issue, I cannot say. But I did just try it with a fresh copy of my repo and running the ZXPSignCmd
commands manually in PowerShell with no trouble.
We're having issues signing an extension on Windows. We have our own .p12 certificate and accompanying password, and while ZXPSignCmd works fine for us on OS X, we get the following errors immediately upon execution on Windows:
Error - Failed to parse signatures.xml. Check for valid XML format.
The only reference to this file that I can find in the docs states that it's generated automatically by ZXPSignCmd. As such, I don't quite understand why it would be complaining about its format.
Any help is appreciated. We're fine in the short term signing the extension on OS X, but it would be nice not to be constrained by that, as we have engineers working on both platforms. We're using 4.0.7 and have tried both x64 and 32-bit builds.