sigild - npm Package Compare versions

Comparing version

0.0.3

0.0.4

+25

-0

CONTRIBUTING.md

		@@ -40,1 +40,26 @@ # Contributing to sigil
		For security issues in sigil itself, open a private GitHub Security Advisory rather than a public issue.

		## Releasing (maintainer only)

		`sigild` publishes to npm via OIDC trusted-publisher auth — there is no long-lived `NPM_TOKEN`. The release workflow at [`.github/workflows/release.yml`](./.github/workflows/release.yml) is the only thing allowed to publish; it triggers on tags matching `v*`.

		To cut a new release:

		1. Land a PR that bumps `package.json` `version` and `server.json` `version` + the inner `packages[0].version` (both must match). Get it into `main`.
		2. Pull `main` locally so your working tree matches the merged commit.
		3. Tag and push:
		```sh
		git tag v0.0.4 && git push --tags
		```
		4. The workflow runs: installs, tests, verifies the tag matches `package.json`, then `npm publish --access public --provenance`. If anything fails, no publish happens.
		5. Optionally: also publish to the MCP registry. `mcp-publisher login github` (if your local token expired) then `mcp-publisher publish`. There's no automated path for the MCP registry yet.

		One-time setup on `npmjs.com` (already done — listed here for documentation):

		- Package settings → Trusted publishers → Add → GitHub Actions
		- Organization or user: `cdrn`
		- Repository: `sigil`
		- Workflow filename: `release.yml`
		- Environment name: `release`

		If that config is ever lost or rotated, every step above will fail with an OIDC auth error until it's recreated. No fallback token by design.

+1

-1

package.json

		{
		"name": "sigild",
		"version": "0.0.3",
		"version": "0.0.4",
		"mcpName": "io.github.cdrn/sigil",
		@@ -5,0 +5,0 @@ "description": "Claude can sign, but never see. MCP server + CLI that keeps private keys out of the LLM's context window.",

+18

-2

README.md

		@@ -156,8 +156,24 @@ # sigil
		- No Bun. Plain Node only. Bun is currently being weaponized by Mini Shai-Hulud as an evasion layer; we will not give that pattern any cover.
		- Planned for v0.1.0 (the real release, not this 0.0.1 placeholder):
		- Provenance attestations on every npm publish via GitHub Actions trusted publishing (OIDC, no long-lived tokens)
		- Provenance attestations on every npm publish. Starting v0.0.4, releases are built by [a GitHub Actions workflow](./.github/workflows/release.yml) under OIDC trusted-publisher auth, signed with a Sigstore attestation. No long-lived npm token; tampered or out-of-band publishes fail signature verification.
		- Still planned for v0.1.0:
		- SBOM (CycloneDX) attached to every release
		- Signed standalone binaries from GitHub Releases for users who'd rather not touch npm
		- Action SHA pinning rotation via Dependabot
		- CI guard that fails the build if any dep in the resolved tree declares `postinstall` / `preinstall` / `prepare`

		## Verifying a release

		You can confirm a `sigild` tarball was built by the public workflow at the commit it claims to come from:

		```sh
		# Validates every package in your install tree:
		npm audit signatures

		# Inspect the attestation for a specific sigild version:
		npm view sigild@<version> dist.attestations
		# → shows the workflow filename, the commit SHA, and the Sigstore signing cert
		```

		What the attestation tells you: this tarball was built by `cdrn/sigil`'s `.github/workflows/release.yml`, at a specific commit on `main`, at a specific time. It does not tell you that commit is non-malicious — for that, read the diff between the version you trust and the version you're upgrading to. But it does mean an attacker who steals an npm token can't publish a malicious `sigild` under our name; they'd need to compromise the GitHub repo + push a tag, which leaves an audit trail.

		## Threat model
		@@ -164,0 +180,0 @@

sigild - npm Package Compare versions

Improved metrics