consolidation of some of the modules, localization fixes, product advisories work, qa work

This commit is contained in:
master
2026-03-05 03:54:22 +02:00
parent 7bafcc3eef
commit 8e1cb9448d
3878 changed files with 72600 additions and 46861 deletions

View File

@@ -2660,4 +2660,92 @@ Meter: `StellaOps.Attestor.ProofChain.Receipts.Sidebar`
null/empty/whitespace throws
- DeriveVerificationStatus: single pass, single fail
- Register: null throws
- RegisterContext: null/empty/whitespace bundleId throws
- RegisterContext: null/empty/whitespace bundleId throws
## Advisory Commitments (2026-02-26 Batch)
- `SPRINT_20260226_225_Attestor_signature_trust_and_verdict_api_hardening` governs:
- DSSE signature verifier trust behavior (including deterministic failure reasons).
- authority roster validation for verdict creation.
- authenticated tenant context enforcement over header-only spoofable inputs.
- deterministic verdict retrieval APIs for hash-based lookup.
- Rekor/tile verification commitments from `Deterministic tile verification with Rekor v2` are coordinated with Symbols sprint `SPRINT_20260226_226_Symbols_dsse_rekor_merkle_and_hash_integrity`.
---
## Trust Domain Model (Sprint 204 -- 2026-03-04)
### Overview
As of Sprint 204, the Attestor module directory (`src/Attestor/`) is the trust domain owner for three runtime services and their supporting libraries:
1. **Attestor** -- transparency log submission, inclusion proof verification, evidence caching
2. **Signer** -- DSSE envelope creation, cryptographic signing (keyless/keyful/HSM), entitlement enforcement
3. **Provenance** -- SLSA/DSSE attestation generation, Merkle tree construction, verification tooling
Source consolidation places all trust-domain code under a single directory for ownership clarity, while preserving runtime service identities and security boundaries.
### Trust Data Classification
| Data Category | Owner Service | Storage | Sensitivity |
|---|---|---|---|
| Attestation evidence (proofchain, inclusion proofs, Rekor entries) | Attestor | `attestor` PostgreSQL schema | High -- tamper-evident, integrity-critical |
| Provenance evidence (SLSA predicates, build attestations, Merkle trees) | Provenance (library) | Consumed by Attestor/EvidenceLocker | High -- deterministic, reproducible |
| Signer metadata (audit events, signing ceremony state, rate limits) | Signer | `signer` PostgreSQL schema | High -- operational security |
| Signer key material (KMS/HSM refs, Fulcio certs, trust anchors, rotation state) | Signer (KeyManagement) | `key_management` PostgreSQL schema | Critical -- cryptographic trust root |
### PostgreSQL Schema Ownership
Each trust-domain service retains its own DbContext and dedicated PostgreSQL schema:
- **`attestor` schema** -- Owned by the Attestor service. Contains `entries`, `dedupe`, `audit` tables for transparency log state.
- **`signer` schema** -- Owned by the Signer service. Contains signing ceremony audit, rate limit state, and operational metadata.
- **`key_management` schema** -- Owned by the Signer KeyManagement library. Contains key rotation records, trust anchor configurations, and HSM/KMS binding metadata.
There is **no cross-schema merge**. Each service connects with its own connection string scoped to its own schema.
### Security Boundary: No-Merge Decision (ADR)
**Decision:** Signer key-material isolation from attestation evidence is a deliberate security boundary. The schemas will NOT be merged into a unified DbContext.
**Rationale:**
- A merged DbContext would require a single connection string with access to both key material (signing keys, HSM/KMS bindings, trust anchors) and evidence stores (proofchain entries, Rekor logs).
- This widens the blast radius of any credential compromise: an attacker gaining the Attestor database credential would also gain access to key rotation state and trust anchor configurations.
- Schema isolation is a defense-in-depth measure. Each service authenticates to PostgreSQL independently, with schema-level `GRANT` restrictions.
- The Signer's KeyManagement database contains material that, if compromised, could allow forging of signatures. This material must be isolated from the higher-volume, lower-privilege evidence store.
**Implications:**
- No shared EF Core DbContext across trust services.
- Each service manages its own migrations independently (`src/Attestor/__Libraries/StellaOps.Attestor.Persistence/` for Attestor; `src/Attestor/__Libraries/StellaOps.Signer.KeyManagement/` for Signer key management).
- Cross-service queries (e.g., "find the signing identity for a given attestation entry") use API calls, not database joins.
### Source Layout (post-Sprint 204)
```
src/Attestor/
StellaOps.Attestation/ # DSSE envelope model library
StellaOps.Attestation.Tests/
StellaOps.Attestor/ # Attestor service (Core, Infrastructure, WebService, Tests)
StellaOps.Attestor.Envelope/ # Envelope serialization
StellaOps.Attestor.TileProxy/ # Rekor tile proxy
StellaOps.Attestor.Types/ # Shared predicate types
StellaOps.Attestor.Verify/ # Verification pipeline
StellaOps.Signer/ # Signer service (Core, Infrastructure, WebService, Tests)
StellaOps.Provenance.Attestation/ # Provenance attestation library
StellaOps.Provenance.Attestation.Tool/ # Forensic verification CLI tool
__Libraries/
StellaOps.Attestor.*/ # Attestor domain libraries
StellaOps.Signer.KeyManagement/ # Key rotation and trust anchor management
StellaOps.Signer.Keyless/ # Keyless (Fulcio/Sigstore) signing support
__Tests/
StellaOps.Attestor.*/ # Attestor test projects
StellaOps.Provenance.Attestation.Tests/ # Provenance test project
```
### What Did NOT Change
- **Namespaces** -- All `StellaOps.Signer.*` and `StellaOps.Provenance.*` namespaces are preserved.
- **Runtime service identities** -- Docker image names (`stellaops/signer`), container names, network aliases, and API base paths (`/api/v1/signer/`) are unchanged.
- **Database schemas** -- No schema changes, no migrations, no data movement.
- **API contracts** -- All endpoints including `/api/v1/signer/sign/dsse` remain stable.

View File

@@ -123,3 +123,15 @@ stella bundle verify --bundle light-bundle/ --replay --blob-source https://regis
- `docs/modules/attestor/guides/timestamp-policy.md`
- `docs/modules/attestor/airgap.md`
- `docs/modules/airgap/guides/staleness-and-time.md`
## 8. Deterministic Error Triage Guidance (Sprint 20260226_225)
Use stable error classes to route remediation:
- `signature_untrusted`: key not present in authority roster; refresh roster snapshot and retry.
- `signature_revoked`: signing key revoked; rotate signer and regenerate attestation.
- `tenant_mismatch`: authenticated tenant differs from verdict owner; re-run with correct principal context.
- `verdict_not_found`: no verdict exists for requested hash; verify hash source and storage replication.
Operator rule:
- Do not treat these as transient network faults unless the error class is explicitly retryable.

View File

@@ -429,6 +429,7 @@ The 13-step verification algorithm:
| 0501.6 | Database Schema Implementation | TODO |
| 0501.7 | CLI Integration & Exit Codes | TODO |
| 0501.8 | Key Rotation & Trust Anchors | TODO |
| 20260226_225 | Signature trust + verdict API hardening | DONE |
## Related Documents