Shipping the Extensions — Marketplace, Open VSX, lateralus.dev
Three Lateralus editor extensions are now live across both major VS Code distribution channels, signed and md5-pinned, with a verified publisher and a domain-bound source of truth. This post walks through the moving parts so the next person doing this — possibly future me, possibly you — has a single page to read.
◉ What Shipped
Three extensions under the lateralus publisher:
lateralus.lateralus-lang— LSP, syntax, formatter, and snippets for.ltlfiles. v3.2.0.lateralus.antikythera-digital— geometric-calculus tooling for.atk, with SDF lattice rendering and live diagram preview. v0.2.0.lateralus.grugbot420— the grug-mode oracle, status-bar wisdom, and multi-model orchestration UI. v1.1.0.
Each one is published to both the VS Code Marketplace and Open VSX from the same .vsix bytes, with matching MD5 sums surfaced on the /extensions/ page.
◉ Dual-Publishing
The packaging step is identical for both registries — vsce package --no-dependencies against the extension's package.json. What differs is the publish step:
- VS Code Marketplace needs an Azure DevOps Personal Access Token scoped to Marketplace > Manage, generated from the same Microsoft account that owns the publisher, with All accessible organizations selected. We learned this the hard way: a token scoped to a single org returns
TF400813with the anonymous-user GUID, which looks like a permission failure but is actually a token-rejection failure that happens before identification. - Open VSX uses a separate token from the Eclipse Foundation's
open-vsx.orgaccount. Same VSIX, different upload endpoint vianpx ovsx publish.
Both registries store icon, banner, and gallery-banner color from the package.json's icon and galleryBanner fields. We baked in proper 256² icons, 512² logos, and 1280×640 marketplace banners for each extension and verified the bytes round-trip by md5-summing the asset inside the published VSIX downloaded back from each registry.
◉ Claiming the lateralus Namespace
Open VSX namespace claims happen in the open: you file an issue at EclipseFdn/open-vsx.org stating that you're the publisher, listing the extensions, and pointing to a verifiable identity (GitHub account, source repos, project domain). Ours is #9925. Once approved, all lateralus.* extensions get the verified-publisher checkmark.
◉ Verifying the Publisher Domain
The VS Code Marketplace verification flow is a domain-based trust handshake using a DNS TXT record:
_visual-studio-marketplace-lateralus.lateralus.dev IN TXT "1b17ce53-…"
Cloudflare auto-appends the zone, so in the dashboard the Name field is just _visual-studio-marketplace-lateralus. The full hostname only appears once you save. Anyone who tries to put the full thing in the Name field ends up with a doubled-up record at ...lateralus.dev.lateralus.dev.
The "may take up to 72 hours" disclaimer is legacy. Cloudflare propagation is consistently under one minute. After that, clicking Verify on the publisher page flips the entire publisher to verified and the blue checkmark appears on every extension simultaneously.
◉ Hosting the Downloads
The /extensions/ portal links each extension to three places: the Marketplace listing, the Open VSX listing, and a direct VSIX served from lateralus.dev/download/vsix/. The direct downloads are useful when corporate environments block one or both registries — and as a tamper-evidence reference, since we publish the MD5 alongside.
For larger artifacts (the LateralusOS ISOs, NullSec Linux images), we use a Cloudflare R2 bucket bound to downloads.lateralus.dev. Public bucket, listing disabled, byte-range requests supported. This avoids GitHub Releases' 2 GB-per-asset cap and gives us cache control we don't otherwise get.
The Pages site itself is direct-upload — no Git connector — which means deploys go through wrangler pages deploy from a token with Account → Cloudflare Pages → Edit + Account Settings → Read. Connecting a Git repo would auto-deploy on push; we'll likely flip to that once the cadence justifies it.
◉ Security Posture
The deployed assets passed a full audit:
- Strict CSP (
default-src 'none', no wildcards, locked-downscript-src,frame-ancestors 'none'). - HSTS preloaded, COOP/COEP/CORP all set to lockdown defaults, X-Frame-Options DENY.
- No inline event handlers, no
<iframe>/<form>on the new pages, all outboundtarget="_blank"links carryrel="noopener noreferrer". - R2 bucket listing disabled — object-by-object access only.
- Pages Functions read every secret from
context.env.*bindings; no hardcoded credentials anywhere in the source tree. - VSIX MD5s on the page match the bytes served, which match the bytes on the registries.
◉ What's Next
The Open VSX namespace claim is filed and waiting on Eclipse maintainer review. The Marketplace publisher is now domain-verified. Next on the list: connect the Pages project to the Git repository so site updates auto-deploy on push, and tag a release on the grug-group420/grugbot420 repo once write access lands. Everything past that is product, not plumbing.