Signet · Elliot Anstey

From idea to a code-signing product that signed itself — in three days

Signet signs any application; the standout demonstration is that it signed its own release build and survived a five-way adversarial verification. Named on July 16, that self-signed, verified build was done by July 18. The first working signing engine existed within the opening afternoon — the speed came from holding the architecture and driving the build against it.

Jul 16 · the idea

Signing shouldn't be a gauntlet — it should be a seal you press.

Named "Signet" and sketched the vision: a heads-up display that runs the whole signing ceremony and asks for a human only at the one moment it matters — the physical key-touch.
Jul 16 · same afternoon

A working signing engine — not a mockup.

Within the first session: the frameless bubble HUD, a step-engine ceremony on a worker thread, and a real Authenticode runner — YubiKey TOTP → cloud-HSM sign → verify → provenance. By that evening it could actually sign. This is also where the architecture landed: the signer follows the distribution, not the other way around.
Jul 17 · made it tough

The problems that make real signing brittle — found and fixed.

Traced and killed a Qt cross-thread deadlock with a watchdog; added a manual-OTP fallback; built the distribution-profile system so each channel gets the correct stages and the correct signer; and calibrated the one-time-code timing to measured latency.
Jul 18 · signature + identity

First real production signature, and a face drawn in code.

Fixed the last hardware-key edges — a touch-required parse quirk, clock skew — and put a valid, timestamped signature on a real release. Then drew the mark: a sealing-wax seal with a twisted-rope rim and the Elder Futhark rune Sowilō (ᛊ) — the rune for the "s" sound, and so for Signet — generated procedurally, and compiled Signet to a standalone 22 MB binary with the seal embedded.
Jul 18 · signs itself

I pointed Signet at its own build and had it sign itself.

A signing tool that can't sign itself is just talk. The moment it compiled, the next move was obvious — the compiled Signet ran its own ceremony and produced a valid, trusted, timestamped signature on a Signet release.
Jul 18 · the proof

Five independent checks tried to break the signature. None could.

Claiming "it's signed" is cheap — so I attacked it five ways, including a tamper test that flips a byte and confirms the signature fails. It failed exactly as it should; the real file passed every check. Idea to a code-signing product — signed by itself, adversarially verified: three days.

What it does

The problem. Signing a release is the fragmented last mile of shipping software. After the build, a developer faces a manual gauntlet — the right signing tool for each artifact type, hardware two-factor, cloud-HSM credentials, RFC-3161 timestamps, signature verification, a provenance record — performed by hand, and differently for every distribution channel. It's slow, easy to get wrong, and disconnected from the otherwise-automated pipeline.

The solution. Signet is a desktop heads-up display for that last mile. Stage bubbles float at the edge of the screen, tracking a build toward production-ready; when it's staged, one Complete & Sign runs the ceremony — pull a fresh one-time code from a YubiKey, sign through the cloud HSM, verify, and write a provenance record — pausing only for the single moment a human is needed: the physical key-touch. Distribution profiles make it channel-aware, because the signing method is a property of the distribution, not the tool.

The value. It produces genuinely production-ready artifacts — a timestamped, trusted-chain Authenticode signature that signtool verify /pa passes with zero errors — from a click and a key-touch. It's self-hosting, and it's engineered to be trusted with a security-critical job: a no-single-point-of-failure key model, crash logging behind a single-instance guard, and hardened handling of the hardware, timing, and platform edge cases that make real-world signing brittle.

stack: Python · PySide6 (Qt) · SSL.com eSigner (CodeSignTool / eSigner KSP) · Windows signtool · YubiKey OATH-TOTP · Windows DPAPI · Authenticode + RFC-3161 · packaged with Nuitka.

See it in action

Signet's signing ceremony completing — every step checked green, ending in a valid Authenticode signature — **Signet signing its own release build.** Each step verifies before the next; the human is needed only for the physical key-touch. It ends in a valid, timestamped Authenticode signature — this is the tool signing the very build it runs from.

Five stage bubbles down the screen edge, each checked green — **The ceremony as a HUD.** Each release stage is its own draggable bubble; they check off as the build advances, and the final one grows the sign button once the rest are green.

Signet's launcher with a distribution picker set to Standalone .exe / installer — **One tool, every channel.** Choosing a distribution sets both the stage sequence and the signing method — a Store submission, a signed sideload package, or a standalone Authenticode download.

The natural next steps

I'd built a tool whose sole purpose is to sign and ready an application for distribution. So the thought that followed was almost inevitable: well — if this thing is going to be official, it's going to have to sign itself. So I pointed it at its own release build and let it run its own ceremony.

The compiled Signet pulled a code from the YubiKey, signed a Signet release through the cloud HSM, verified the result, and wrote its provenance — the tool producing a valid, trusted, timestamped signature on itself.

It's not a gimmick; it's the strongest possible statement of confidence. If the tool can put a genuine, verifiable signature on a 22-megabyte binary, then that binary — itself — is fair game. Signing itself was never the goal — it's the proof the tool works.

Proof: adversarially verified

"It's signed" is a claim. So I tried to break it — five independent checks, each attacking a different failure mode, each told to refute the signature rather than confirm it. Every one held.

Attack angle	What was attempted	Verdict
Policy verify	signtool verify /pa /v · /all	0 errors, 0 warnings
Chain & revocation	.NET X509Chain, online revocation, entire chain; root checked in both trust stores	trusted, not revoked
Tamper test	flip a single byte in a copy — the signature must fail	rejected · HashMismatch
Timestamp	signtool verify /pa /tw	valid through 2034
Signer & bytes	cert thumbprint + subject; file SHA-256 vs the signed provenance record	exact match

The decisive one is the tamper test: flipping a single byte in a copy dropped verification to WinVerifyTrust 0x80096010 / HashMismatch, exactly as it should — proving the passing result on the real file is meaningful, not a tool rubber-stamping whatever it's handed. The signature chains to a publicly-trusted SSL.com root (present in the machine's trusted-root store), carries a valid RFC-3161 timestamp so it survives the signing certificate's 2027 expiry, and the file's bytes match the SHA-256 in its own provenance record. Two independent verification stacks and five adversarial lenses agreed: it holds.

Engineering notes

A few of the real problems solved along the way:

Distribution-aware signing. One artifact type can't be signed like another — an MSIX package won't go through the same tool as an EXE. Signet routes each distribution to the correct signer (a cloud-HSM CLI, the eSigner key-storage provider, or a Store hand-off).
Hardware second factor, no single point of failure. The signing one-time password comes from a YubiKey, with the seed enrolled on two keys plus a phone — lose one and signing still works — and it's fetched fresh at sign-time to survive the signer's clock-sensitive validation.
A deadlock, traced and killed. The ceremony froze on launch; a fault-handler watchdog caught a GUI update running on the worker thread. Fixed the threading, then added a single-instance lock and crash logging so a security-critical tool can never fail silently.
The compiler couldn't see the signers. The runners were loaded by dynamic import, invisible to the Nuitka static analyzer, so the first packaged build shipped without them. Root-caused from the runtime error and fixed by explicitly including the package.
Self-hosting. Compiled to a standalone Windows binary and signed by itself — the ceremony above is Signet signing its own build, and the signature passed a five-way adversarial verification.