On Windows some sites have policies in place to allow running only binaries with certain properties.
Thus we need to have mostly unique names in all our binaries. The suggestion is to use
VALUE "ProductName", "GnuPG (VS-)Desktop\0"
Note that for the included GnuPG engine we use "GNU Privacy Guard (GnuPG)\0" which we won't change.
| rW Gpg4win | |||
| rW46438040c8cc Add windows VERSIONINFO to all signed binaries | |||
| rW3ede4ebcb691 Fix gccwrap FILEVERSION | |||
So, what is the state of this. Did a change already land in Kleopatra and how can we assure that all binaries have a W32INFO_PRODUCTNAME in their rc file?
I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.
But I am unsure how to handle all the DLLs. maybe if we fix it for now for the exe files? There I think only Gpg4win-tools needs the files.
Now that I think about this. Maybe an intelligent extensiob to extra-cmake-modules would make sense which generates such a file based on the metainfo but allows a generic way to override the values at bulid time. I would like to have sunes / ingos opinion on that.
Phew. Got it. a new script: "gccwrap.sh.in"
gccwrap.sh.in wraps gcc / g++ in the new native tools installation prefix. Then it checks if a dll or exe should be the result of the current call and if that binary neither contains the name conftest (for autotools) or cmTC (for cmake). This is done early to keep the performance impact to a minium.
Then it checks if the output dll / exe is part of AUTHENTICODE_FILES in gpg4win.mk.in. If so then it generates a versioninfo.rc and gpg4win.w32-manifest file for that project, compiles them with windres and adds the resulting object to the linker command line.
Additionally gccwrap.sh.in contains a blacklist of binaries that already have versioninfos but which are not caught by the checks. E.g. Kleopatra where the linked objects are not visible directly on the command line.
BINS_WITH_VERSIONINFO="kleopatra.exe"
Here is a screenshot where you can see that the Generic Details for libarchive and libical, and while they similar they actually set the Fileversion correctly. And for gettext and Kleopatra it should just show that their versioninfo is not overwritten.
Funnily enough, developing this I noticed after some debugging that my reference GnuPG libraries (libgpg-error et. al) did not have the details populated.
The reason for this is that they have to define VarFileInfo, to mark which language the versioninfo is in.
To verify that just open the properties of e.g. libgpg-error-0.dll on Windows.
See: https://learn.microsoft.com/de-de/windows/win32/menurc/versioninfo-resource
so we need to add the following in those versioninfo.rc files:
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1200
ENDSince those are either included as binaries or have a versioninfo.rc already they are now the only ones missing a "proper product name".
But I do not think that this is important or a release blocker as this was never the case and so it is not something that is a regression or worse then at any time before
and I think that since we started signing all binaries with 3.2 this is probably less important as any exceptions or wildcards regarding the publisher should now be possible
using the authenticode signature.
@werner can you give this a quick review and say if I should backport it to master? I am happy keeping this for the next feature release where I am working on in my branch. It does not have a regression risk that I can see per se but since it also does not address a bug I would in principle not backport it.
To clarify what I mean by the missing VarFileInfo block. Currently the GnuPG binaries have versioninfo.rc files but only the version number is displayed for dlls as their pattern did not have the VerFileInfo block: The libassuan-0.dll displayed in this screenshot is from the 2.2.43 package and the assuan-9.dll is self compiled but including the patch below that. I would like to commit such a patch to all libraries that require it if that is okay with you.
diff --git a/src/versioninfo.rc.in b/src/versioninfo.rc.in index 1e96245..0a1079b 100644 --- a/src/versioninfo.rc.in +++ b/src/versioninfo.rc.in @@ -28,7 +28,7 @@ VS_VERSION_INFO VERSIONINFO FILEFLAGS 0x20L #endif FILEOS 0x40004L - FILETYPE 0x1L + FILETYPE 0x2L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" @@ -49,4 +49,8 @@ BEGIN VALUE "SpecialBuild", "@BUILD_TIMESTAMP@\0" END END + BLOCK "VarFileInfo" + BEGIN + VALUE "Translation", 0x409, 1200 + END END
Okay. let me do that for the next library releases.
What is 0x409 and 1200? Or 1033 and 1200 ?
I think the executables also use the same values for translation.
So I have implemented this using the files gpg4win.w32-manifest.in.in versioninfo.rc.in.in in Gpg4win/src. During configure the templates are filled with generic strings which are the same accross one build like product name and product version. And then when we detect a link of a file listed in AUTHENTICODE_FILES a file is generated with File Version and File name. This is done by installing a wrapper around gcc and g++ in the native install dir. (We now have, install, install-ex and install-native as prefixes under playground) that checks if it is currently called to link one of the binaries listed in AUTHENTICODE_FILES. It might be improved if we would write the AUTHENTICODE_FILES variable into that script directly instead of reading it during runtime.
If this is detected it will write out a versioninfo and manifest and compile the versioninfo and add the resulting object to the link command line.
I have not filled out Copyright since IMO we cannot fill this automatically for third party libraries. Some dlls, like iconv, already have a versioninfo.rc. So just using the Product Name to check whether or not to allow the execution of a file would still fail but as I mentioned earlier I doubt that it is really needed for that and we would have the same Problem with GnuPG binaries, which can be included into multiple products.
This is the current state:
And the code for that is in gccwrap.sh.in https://dev.gnupg.org/source/gpg4win/browse/kf6/src/gccwrap.sh.in$129