I’m trying to understand the Windows codesigning process for signing exported applications using Godot 4.x. Following the Godot Windows export tutorial I think I understand the setup needed in Godot for setting the path to Signtool and my signing certificate.
However, when reading the linked microsoft description for how to generate a certificate (at least for testing) it mentions as one of the first points that the Publisher name in the certificate must match the publisher information in your AppxManifest.xml (some application package?). And I assume this is the same if you purchase a certificate from a certificate authority.
In the Godot export process, where/how is this AppxManifest.xml publisher information set so that the exact same information can be used in the signing certificate?
The Godot windows export docs also warn that “If you export for Windows with embedded PCK files, you will not be able to sign the program as it will break.” . Is this still true, or is this information outdated? And “break” in what way?
Since the point of code signing is to prevent tampering with distributed content (at least warn the user about it) and all scripts for the exported project are stored in the PCK as I understand it signing the .exe with the pck embedded seems like the natural way to do it?
AppxManifest is a UWP thing; it isn’t used in Win32 applications like Godot. In Win32 applications, the publisher field is set in the executable (you can do this on export after setting up rcedit in Godot).
And yes, PCK embedding still can’t be used with codesigning as of 4.3.dev3.
Where you can set things like Company name, version etc? This looks like it sets some fields in StringFileInfo for the application, the Win32 version of the AppxManifest? Since this standard doesn’t seem to have a “Publisher” field, does this mean that there’s nothing that needs to match the certificate when signing a win32 application?
Regarding the embedded PCK breaking codesigning, is this due to the content of the pck changing for some reason when the application is run on the user system? If signing the pck isn’t possible, are there any other checks in place to detect if the .pck has been modified?
That said, I don’t know if there’s actually a strict need to have this match the name in the certificate. Back in the days of Certum open source code signing certificates, there were lots of certificates with “, Open Source Developer” publishers in the certificate, but the publisher field in the installer/executable was completely different.
Ok, thanks for the answers. I’ll leave this open in case someone else with experience in doing this has more information to share. Otherwise I’ll just have to do some trial and error, and if/when I figure it out and get it working I can make a proposal for the export docs to document how to set this up.
Regarding the PCK signing it’s good this is being worked on, but this looks like a cross-platform solution with a lot of extra steps needed. Like setting up and managing separate keys and making a custom build of the engine. Perhaps the main use case is for linux if there’s no OS system there for signing? But it seems redundant on macOS where there’s already notarization of the entire package and on windows there is SignTool and that you need to use for signing the executive with SignTool as well anyway. If SignTool can’t sign the .exe with the pck embedded, getting the separate pck file signed with SignTool and the same certificate, and then using that to verify the signature seems like it would be a lot easier?
I was told by bruvzg that PCK embedding and codesigning should work at the same time if the PCK is embedded before the binary is signed (I don’t know if Godot currently does it in this order).
Great, thanks for looking into it. And I think this would then be a good reason to do the signing last if this is not the case today.
If signing with embedded pck was supported I think it would be a great improvement especially for non-game development with Godot where code-signing will be more or less required as you’re not distributing via Steam or such and distributing as a single .exe package will be desirable.
