Diff: services/fs-anchor-emitter.es
From 4e107c0 to 4e107c0
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "FS anchor emitter" | title: "FS anchor emitter" |
| slug: fs-anchor-emitter | slug: fs-anchor-emitter |
| category: services | category: services |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: "fs-anchor-emitter generates signed checkpoints of the immutable Write-Once-Read-Many ledger at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform." | short_description: "fs-anchor-emitter generates signed checkpoints of the immutable Write-Once-Read-Many ledger at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform." |
| status: active | status: active |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: current-fact | bcsc_class: current-fact |
| last_edited: 2026-05-25 | last_edited: 2026-05-25 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: fs-anchor-emitter.es.md | paired_with: fs-anchor-emitter.es.md |
| --- | --- |
| `fs-anchor-emitter` is the component that generates signed checkpoints of the immutable Write-Once-Read-Many ledger at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform itself. The emitter operates at Layer 4 of the WORM stack, reads the latest state of the per-tenant tile tree, generates a `signed-note` checkpoint, and stores it at the authoritative path under `$FS_LEDGER_ROOT/<moduleId>/checkpoint`. The monthly workspace anchoring process consumes those checkpoints and posts them to the public transparency log. | `fs-anchor-emitter` is the component that generates signed checkpoints of the immutable Write-Once-Read-Many ledger at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform itself. The emitter operates at Layer 4 of the WORM stack, reads the latest state of the per-tenant tile tree, generates a `signed-note` checkpoint, and stores it at the authoritative path under `$FS_LEDGER_ROOT/<moduleId>/checkpoint`. The monthly workspace anchoring process consumes those checkpoints and posts them to the public transparency log. |
| ## Configuration Requirements | ## Configuration Requirements |
| The emitter requires the following environment variables to be defined at runtime: | The emitter requires the following environment variables to be defined at runtime: |
| | Variable | Description | Standard Value | | | Variable | Description | Standard Value | |
| | :--- | :--- | :--- | | | :--- | :--- | :--- | |
| | **FS_LEDGER_ROOT** | Path to the tenant storage root. | `/srv/platform/ledgers/` | | | **FS_LEDGER_ROOT** | Path to the tenant storage root. | `/srv/platform/ledgers/` | |
| | **FS_SIGNING_KEY** | Path to the tenant private key (Ed25519). | `/etc/foundry/keys/tenant.key` | | | **FS_SIGNING_KEY** | Path to the tenant private key (Ed25519). | `/etc/foundry/keys/tenant.key` | |
| | **FS_ANCHOR_INTERVAL** | Frequency of checkpoint generation. | `3600s` (1 hour) | | | **FS_ANCHOR_INTERVAL** | Frequency of checkpoint generation. | `3600s` (1 hour) | |
| ## Implementation of the Signed-Note Format | ## Implementation of the Signed-Note Format |
| Checkpoints must strictly follow the **C2SP signed-note** format to ensure interoperability with the Sigstore ecosystem. A valid emitter output includes: | Checkpoints must strictly follow the **C2SP signed-note** format to ensure interoperability with the Sigstore ecosystem. A valid emitter output includes: |
| 1. **Origin:** The service identifier (e.g., `service-fs.foundry.example`). | 1. **Origin:** The service identifier (e.g., `service-fs.foundry.example`). |
| 2. **Tree Size:** The current monotonic entry count. | 2. **Tree Size:** The current monotonic entry count. |
| 3. **Root Hash:** The base64-encoded SHA-256 Merkle root. | 3. **Root Hash:** The base64-encoded SHA-256 Merkle root. |
| 4. **Signature:** A detached Ed25519 signature from the tenant key. | 4. **Signature:** A detached Ed25519 signature from the tenant key. |
| ## Operational Procedures | ## Operational Procedures |
| ### Bootstrapping a New Emitter | ### Bootstrapping a New Emitter |
| Upon first initialization, the emitter verifies the presence of the `FS_SIGNING_KEY`. If no prior state exists, it generates a "Tree Size 0" checkpoint to establish the ledger’s origin. | Upon first initialization, the emitter verifies the presence of the `FS_SIGNING_KEY`. If no prior state exists, it generates a "Tree Size 0" checkpoint to establish the ledger’s origin. |
| ### Verification of Consistency | ### Verification of Consistency |
| Before emitting a new checkpoint, the emitter is intended to perform an internal consistency proof against the previously signed state. If the new hash-chain does not append cleanly to the old one, the emitter must abort and trigger an infrastructure alert (SOC 2 CC7 alignment). | Before emitting a new checkpoint, the emitter is intended to perform an internal consistency proof against the previously signed state. If the new hash-chain does not append cleanly to the old one, the emitter must abort and trigger an infrastructure alert (SOC 2 CC7 alignment). |
| ## External Anchoring | ## External Anchoring |
| While the emitter produces checkpoints hourly, external publication to Rekor is currently planned for a monthly cadence. This provides a balance between evidentiary density and network overhead. | While the emitter produces checkpoints hourly, external publication to Rekor is currently planned for a monthly cadence. This provides a balance between evidentiary density and network overhead. |
| ## See also | ## See also |
| - [[service-fs-architecture]] | - [[service-fs-architecture]] |
| - [[service-fs-security-compliance]] | - [[service-fs-security-compliance]] |
| - [[worm-ledger-design]] | - [[worm-ledger-design]] |