Re: Windows signing restored

On Mittwoch, 26. August 2026 14:00:26 Mitteleuropäische Sommerzeit Ben 
Cooksley wrote:
> This evening I have completed the necessary setup to restore Windows
> signing using our new certificate.
> 
> Conventional Windows signing should now be operational again.

Excellent! Thanks for your work!

> Unfortunately due to assumptions in Craft surrounding how X.509 certificate
> subject names are constructed, it is not possible to restore appx signing
> at this time as it fails due to the following error:
> 
> Aug 26 11:09:02 jarvis python[30701]: java.lang.IllegalArgumentException:
> The app manifest publisher name (CN=K Desktop Environment e. V., O=K
> Desktop Environment e. V., S=Berlin, C=DE) must match the subject name of
> the signing certificate (SERIALNUMBER=VR
> 31685,jurisdictionCountry=DE,BusinessCategory=Private
> Organization,C=DE,ST=Berlin,O=K Desktop Environment e.V.,CN=K Desktop
> Environment e.V.)
> 
> (Note for those looking to update our Craft configuration - the above is
> not the subject name that Windows will accept, you need SERIALNUMBER=VR
> 31685, 1.3.6.1.4.1.311.60.2.1.3=DE, 2.5.4.15=Private Organization, C=DE,
> S=Berlin,  O=K Desktop Environment e.V., CN=K Desktop Environment e.V. for
> that)

Should be easy to fix be (optionally) replacing the fine grained CodeSigning/
CommonName, CodeSigning/Organization, CodeSigning/State, etc. settings with a 
simple CodeSigning/DistinguishedName setting.

> Craft also fails to pick up this failure and reports success.
> 
> While validating this functionality I also observed that Craft is
> performing an excessive number of signing operations. The first it does
> when doing the initial build, with subsequent signings being done for the
> tarball / exe installer and the files to be used in the appx packaging.
> 
> The result of this is:
> - Longer time to build as we do 3 trips to the Notary for the same set of
> files
> - should be 1 (which wastes CI builder time)

I'm not sure this is possible because we need to sign all binaries that are 
put into the installer. And then we need to sign the installer executable. The 
only way to avoid this would be to let the notary create the packaging which 
means we'd have to upload even more files to the notary. Currently, we only 
upload binaries that need signing.

> - More signing operations being performed (which means greater cost for us,
> as the new certificate lives in a HSM and usage is a charged for -
> thankfully the cost is minimal)
> - Executables / dlls having two signatures on them (probably going to
> upset/break something somewhere)

Yes, we shouldn't sign any binaries multiple times. We/Craft could probably 
check which binaries are already signed.

Craft usually already signs package binaries that are added to the cache. To 
avoid re-signing of already signed cached packages we run `craft --install-
deps` with "[CodeSigning]Enabled=False". The downside is that binaries of not 
cached dependency packages are then unsigned. `craft APPNAME` is called 
without explicit code signing option so that it defaults to signing (as per 
the setting in the CraftConfig.ini in craft-ci).

`craft --package` is then called explicitly with "[CodeSigning]Enabled=True". 
If I remember correctly Craft (tries to) keep(s) track of which binaries are 
already signed so that only unsigned binaries are signed when an app is 
packaged.

> - The resulting files in the .appx and .exe/.7z bundles having different
> signatures / hashes

Maybe we can simply disable signing when building the appx. All binaries are 
already signed and the appx upload file that we upload to the Microsoft Store 
doesn't need to be signed. Only the sideload appx needs to be signed. If Craft 
would check which files are already signed then it would just sign the sideload 
appx.

This would still be a separate roundtrip. I don't think a few roundtrips are a 
real problem. Especially for fat installers the most time is spent uploading 
and downloading and that scales linear. Two roundtrips to sign two different 
artifacts (app.exe and app.appx) don't take that much longer than one 
roundtrip which signs both artifacts.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCao8JHxsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIACgkQsW9ZlRZHSrpm1gEAokFbBqCdD+wtHt7ePSwh
+2nulcDNXd/SmOEoYYFE2xgBALQbyyyEu2nQojEsu2SUqEq09TEN/KXkHM2dic1s
65UD
=6bVh
-----END PGP SIGNATURE-----