Support multiple signature types about signify HOT 6 CLOSED

We appear to do this in https://github.com/ralphje/signify/blob/master/signify/signed_pe.py#L256-L267 as at least one of the SignedDatas must be valid. I'm not sure that this is the correct approach though, as you are correct that if there are both a SHA-1 and SHA-256 certificate, we may want to prefer only checking the SHA-256 one.

Do you know how we should approach this, and how Windows handles when either one of the signatures is invalid?

from signify.

I've been actively trying to parse binaries's multiples signatures with signify without much success.
The code you mentioned in signed_pe.py seems correct to me, but signed_datas yield only 1 object thus ignoring other signers.

Window considers SHA1 signatures to be deprecated unless it has been countersigned.
SHA256 should be prefered but the various tools available on W10 only checks the first signing (just like your lib).

Can the lib pull multiples signing without heavy modification of source ?
PS : I added a dump of various tools that checks signatures on windows (signcheck, get-authenticodesignature, my POC using signify)
dump.txt

from signify.

The issue seems to originate from a totally different use case: one SignerInfo with multiple certificates. This seems to be handled by adding an unauthenticated attribute in OID 1.3.6.1.4.1.311.2.4.1 to the SignerInfo class. We aren't currently parsing this, though we probably should.

from signify.

Could you verify that the above commits yields more expected results?

from signify.

Hey @ralphje , you were on point with mutliples signatures beeing nesteds. It is working far better than the sysinternal tool now :
MicrosoftEdgeSetupBeta (2).txt
Thanks !

from signify.

This issue was still open, since I wanted to research how Microsoft handles the case of multiple signatures where only one is correct. Basically, the Microsoft default is only checking the first signature (at least in sigcheck.exe, Get-AuthenticodeSignature and signtool without /all). Note that the /as option of signtool speaks about a 'primary' signature, whichever that may mean, but I gather this is what they mean with that.

The other option is signtool with /all, which will show you that one is correct and the other isn't -- it doesn't provide any further guidance on what to do with that.

Since there is no clear concensus about this, I have added a multi_verify_mode argument to allow customization by the caller, allowing the 'first' signature, 'all' signatures or 'any' signature to verify, and in spirit of your remarks, I have added the option to verify the 'best' signature as well.

For now, the Signify default remains to be 'any'.

from signify.