FS anchor emitter
fs-anchor-emitter connects the platform's immutable Write-Once-Read-Many ledger to a public, third-party transparency log. It doesn't generate the ledger checkpoint itself — service-fs does that — the emitter's job is to fetch an already-signed checkpoint, submit it to Sigstore Rekor, and record the result. This design keeps checkpoint generation and public anchoring as separate, independently-auditable steps.
What it does, in order
The emitter is a one-shot binary, invoked on a schedule by an external process rather than running its own timer:
- Fetch.
GET /v1/checkpointfromservice-fs, scoped to the running tenant's module ID. The checkpoint carries an origin string, a monotonic tree size, a base64 Merkle root hash, and — already applied byservice-fs— a signature and public key. - Anchor to Rekor. The checkpoint is serialised, hashed with SHA-256, and wrapped in a Sigstore
hashedRekordRequestV002entry (Rekor v0.0.2's request shape). The emitter generates a fresh Ed25519 keypair for this step alone, on every run — that ephemeral key exists only to produce the Rekor timestamp and inclusion proof, not to assert a persistent identity. The request is posted to the configured Rekor endpoint. - Write back. The resulting transparency-log entry is posted to
service-fs's/v1/append, so the platform's own record shows exactly what was anchored publicly and when.
Configuration
Three environment variables, read once at startup:
| Variable | Purpose | Default |
|---|---|---|
FS_ENDPOINT |
Base URL of the service-fs instance to fetch from and write back to |
none — required |
FS_MODULE_ID |
Tenant module scoping the checkpoint fetch | none — required |
REKOR_URL |
Rekor log-entries endpoint | log2025-1.rekor.sigstore.dev's v2 API |
A distinct exit code identifies where a run failed: configuration error, checkpoint fetch failure, Rekor submission failure, or the final write-back to service-fs.
Cadence and scope
The binary itself has no internal generation or consistency-proof logic — both would require holding ledger state, which this design deliberately keeps out of the anchoring step. Its own source identifies it as "Doctrine Invention #7," documented as monthly Rekor anchoring of service-fs checkpoints — a deliberate balance between evidentiary density and network overhead, not a technical ceiling on how often it could run.
See also
- service-fs — the WORM ledger backbone — generates and signs the checkpoints this emitter fetches
- WORM ledger design — the ledger the checkpoint attests to
service-fs— the compliance posture this anchoring supports