Page MenuHome GnuPG

Sign GpgOL to support group deployments
Open, WishlistPublic



I understand that signing the GpgOL binary directly with Authenticode
will have the benefit, that it can be rolled out easiler to a group of users.

by default we use the Group Policy object to block all add-in for outlook

and we also use gpo's and a white list to allow all know but certified add-in like:

"To trust an add-in for all users of a machine, it must be signed with a Trusted
Publisher’s Certificate (See Authenticode Certificates in Granting Trust to Office
Solutions and How to: Add a Trusted Publisher to a Client Computer for ClickOnce
Applications for more information)"

Let us find out how easy this is and how much we gain first.
@Andre, what do you think?

Event Timeline

I would rather add a "Sign all binaries" installed by us capability to the
packaging process then a special case handling for GpgOL. Especially for the
Uninstaller this would make sense at it requires privileged execution and is
currently unsigned.

But this would mean that we either need to split up the packaging process to
first create the binaries and on a different system (with the code signing
certificate available) create the NSIS Packages.

Or that we expose the CodeSigning certificate to the build system, which
probably makes the most sense as the build system already should be a secured
environment and we only build / execute code which we verified.

I could imagine implementing this as a configure option --with-codesigning-cert
or something thats optional during the build and which you can provide with the
certificate file.

Reading about

made me think that signing all binaries may not be the best idea. For our
installer we can rule out that it does something malicious as we control what it
does. So signing it is fine. Same goes probably for GpgOL etc.

But the actual encryption stuff (libgcrypt / gnupg) can, of course, be used for
malicious purposes. So there would be the potential for malware using binaries
signed by us. This could hurt our reputation. (technically in terms of Windows
Code Signing Reputation or Anti Virus software)

At least something we should keep in mind while thinking about changes to what
we sign.

For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom during the build process. By default the path to the included is gnupg-vsd/ in the src repo. But that can be changed of course.

# Signging host/key setup for codesigning
-include gnupg-vsd/

So this issue can be closed in my opinion as there is a way to custom sign the compiled binaries on windows with a token during the automatic build of packages in the Gpg4win repo. It's required to configure this but this can't be avoided. The generic build of Gpg4win produces unsigned binaries that have to be manually signed.