Re: Windows signing restored

On Thu, Aug 27, 2026 at 3:41 AM Ingo Klöcker <[email protected]> wrote:

> 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.
>

Sorry need to clarify here, it is doing three trips as it signs when:
- Initially building the application
- Packaging it into a .exe installed / .7z archive
- Packaging it into a .appx

Note that i'm referring to the files inside the archive / installer / appx
here, not the actual .exe/appx.

In total it is 5 signing operations (one each for the .exe installer and
the .appx bundle) - but those two as you note can't be avoided.


>
> > - 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
>

Cheers,
Ben