[sashyo]

Gives you the two DLLs and a ready-to-sign CAB straight from CI, so getting TideSSP through Microsoft's file signing service doesn't need a local Windows toolchain.

Why this is needed at all

TideSSP.dll and TideSubAuth.dll load into LSASS. Under LSA Protection — default on clean Windows 11 22H2+ installs — LSASS loads only modules carrying a Microsoft signature. That's the "This module is blocked from loading into the Local Security Authority" dialog.

An EV certificate can't produce that signature. It authenticates your Partner Center account and signs the submission; Microsoft signs the binaries and returns them.

What the release build now produces

Artifact	What it's for
TideSSP-lsa-signing-request	TideSSP-LSA.cab plus both DLLs — download, sign the CAB, submit
TideSSP-installer-unsigned	The MSI, renamed — built from unsigned DLLs, so it will not load under LSA Protection

The CAB is deliberately unsigned: an EV key lives on hardware CI can't reach, so signing stays local.

TideCA.dll is excluded from the CAB — it's an MSI custom action running in msiexec, never in LSA, so your own EV signature covers it.

The MSI rename matters. The old name suggested a shippable installer; it never was on an LSA-protected machine. The shippable one is built from the DLLs Microsoft returns.

The flow

1. Run Release  →  download TideSSP-lsa-signing-request
2. signtool sign /fd sha256 /sha1 <EV thumbprint> \
     /tr http://timestamp.digicert.com /td sha256 TideSSP-LSA.cab
3. Partner Center → Hardware → Submit new hardware → upload the CAB
4. Days later: download the Microsoft-signed DLLs
5. Commit them to tide-ssp/signed/ with MANIFEST.md
6. Build the MSI against those, and do NOT re-sign them —
   your signature replaces Microsoft's and LSA rejects them again

tide-ssp/signed/README.md documents step 5 onward, including why the source commit is recorded: a signature covers exact bytes, so any change to src/ssp.c invalidates it and needs a fresh submission.

Testing

None of this has been executed. makecab, signtool and PowerShell are all Windows-only and absent here, so the script is unrun and the CI step unproven. What I did check: the workflow YAML parses and sequences the new step after the DLL build and before the MSI.

Worth a -SkipSign run first so you can open the CAB and confirm its layout before spending a submission on it. The script warns if a DLL already carries an Authenticode signature, since submitting a pre-signed binary is a common way to waste a round trip.