Closed ebourg closed 1 year ago
Great news Emmanuel!
Actually I have seen the new versions and wanted to try them out but have not had a chance yet.
I think so far we have mostly been using Jsign for PE and PowerShell but many other looks interesting as well. With the great structure of Jsign I am thinking that we should refactor the Authenticode signers in SignServer so that they would work with any format supported by Jsign without the special handling for each of the formats that we currently have in SignServer.
There is a dependency on jsign-core but no actual usage in the code (besides the copied DigestAlgorithm class). What did I miss?
Yes you are right. Actually the Authenticode support is currently only in Enterprise Edition so that is why you could not find it here. (Documentation is here https://doc.primekey.com/signserver/signserver-reference/signserver-workers/signserver-signers/ms-authenticode-signer where it is marked as an enterprise feature.)
We have updated to use Jsign 5.0. However, we discovered the changes in the signature algorithm OIDs from for instance SHA256withRSA to rsaEncryption as well as the removal of cmsAlgorithmProtection signed attribute.
Some of our users are sensitive to any changes in the signature formats so for now we had to revert those changes and for now have our own version of that class.
I suppose those changes were made to have a more similar (or even exactly the same) signature output as what you get from signtool? If so, I think those are good changes but for SignServer we need to think of how to roll out those changes to our users. Maybe we will need a configuration option so that users having trouble with it could switch back to the old format.
We have updated to use Jsign 5.0. However, we discovered the changes in the signature algorithm OIDs from for instance SHA256withRSA to rsaEncryption as well as the removal of cmsAlgorithmProtection signed attribute.
Some of our users are sensitive to any changes in the signature formats so for now we had to revert those changes and for now have our own version of that class.
Do you mean that this change triggered validation issues? Or do you fear that it could be disruptive?
I suppose those changes were made to have a more similar (or even exactly the same) signature output as what you get from signtool?
Yes that's the goal. If you have an explicit use case where diverging from signtool is desirable, I'm willing to add a parameter to make it possible.
The changes from the forked 3.1-signserver5.5 version were merged in the version 4.0, and several improvements relevant to signserver have been made: