Git BASH: exe setups from gog.com are failing with signature error

[DMI-1407]

I am using the script on windows 10 with git bash. I assigned the paths to the 2 external tools correctly and also assigned the path to the cert. For some reason no matter which setup i scan every exe will be reported with an "digital signature error".

Is this known ? Which informations do you need to reproduce this issue ?

[hippie68]

Known is that someone else who used Git BASH had signature errors, too. He is now using Cygwin instead: https://github.com/hippie68/gogcheck/issues/3

The problem probably boils down to how to provide the Windows version of osslsigncode with compatible certificate bundles. Judging by their README, it requires you to specify files that osslsigncode is explicitly built against. At first glance, the Git BASH ca-bundle.trust.crt file seems incompatible.

Unless someone else who has done it before chimes in: IMO the quickest solution for Windows 10, if WSL is not an option, is to use Cygwin (see #3).

[hippie68]

Perhaps it could work by using this file: certfile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

[hippie68]

It is confirmed that the above file works on Windows 11, using the latest release of osslsigncode.exe. The updated script contains the new file suggestion for Git Bash.

Let me know if, against expectation, the errors persist on Windows 10.

[hippie68]

You can now generate a certfile with the "makecertfile" script: https://github.com/hippie68/gogcheck/blob/master/makecertfile. It should solve any problems caused by using wrong bundle files.

[Ammako]

I use WSL, and that error happens. Without running makecertfile I get PKCS7_verify error, not entirely unexpected, but even with the certificate file generated by makecertfile, it fails.

[hippie68]

Please try this new script version, which tries to download each and every digicert certificate, to see if it works: makecertfile.zip

[Ammako]

No luck, unfortunately. Which is strange, because it definitely worked before. The only difference is that I got rid of my WSL distro and reinstalled a fresh one a few weeks ago, so maybe it's missing packages or something that the old install had and it's making it fail.

edit: Arch Linux on WSL, a manual install using the Arch Linux bootstrap, for what it's worth. I could try making a Ubuntu install or something and see if that works, but it definitely worked fine before with Arch, anyway.

Using the old version of the script from f80e8ef2fd226366adb9f067de439dacb8b01690 that I knew for sure works, using an older game installer that I know for sure was valid, it also fails, so it's probably not an issue with the script itself. It's got to be some kind of incompatibility with my setup.

For what it's worth, maybe I should have mentioned it before, but this happens within the script, and I guess it's breaking Signer no.2 certificate and preventing the signature verification from working.

Without external certs:

Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCerFaild to decode CRL from http://crl3.digicert.com/sha2-assured-cs-g1.crl
805014DC367F0000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
805014DC367F0000:error:0480006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:773:
t Assured ID Root CA

With external certs:

Issuer : /C=US/O=DigiCert Inc/OFaild to decode CRL from http://crl3.digicert.com/sha2-assured-cs-g1.crl
802018FE877F0000:error:0680008E:asn1 encoding routines:asn1_d2i_read_bio:not enough data:crypto/asn1/a_d2i_fp.c:216:
802018FE877F0000:error:0480006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:773:
U=www.digicert.com/CN=DigiCert Assured ID Root CA

Weird how it's basically the same error both times, but the "Faild to decode CRL" error cuts the issuer line at different points depending on whether I use an external cert file or not.

(btw, this doesn't really seem to be the same problem, after all. Would it be better to close this, and move this to a separate issue?)

[hippie68]

Yes, it's a different error, and most probably not related to the script. The messages are about OpenSSL source code. Make sure that osslsigncode is properly compiled (ideally from the source code of a release version).

[Ammako]

I'm building from 2.9 release, I guess I could always try building 2.6 release instead since I know that one worked at the time.

It's possible that 2.9 could have a bug though, or some kind of incompatibility with the way this script uses it. Can you (or someone else) confirm if it works for you/them with osslsigncode 2.9?

It builds fine for me, but sometimes toolchain incompatibilities can make successful builds that don't actually work as expected, and that's difficult to debug.

[hippie68]

2.9 compiles and works well with gogcheck on Debian 12 for me. Perhaps it's an Arch issue.

[Ammako]

Well I downgraded osslsigncode to 2.8, and everything works as expected. So maybe osslsigncode 2.9 has an incompatibility with OpenSSL 3.3.1 or something. Either way, problem solved, not a gogcheck issue, and if somebody else runs into the same issue I had here, maybe they can find this solution here now.