stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

audit work, fixed StellaOps.sln warnings/errors, fixed tests, sprints work, new advisories

Browse Source
This commit is contained in:
master
2026-01-07 18:49:59 +02:00
parent 04ec098046
commit 608a7f85c0
866 changed files with 56323 additions and 6231 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/security/auth-scopes.md
View File

@@ -1,11 +0,0 @@
# Auth Scopes
- Pending OAuth2/PAT scope matrix + tenancy header rules.
## Pending Inputs
- Scope matrix + tenancy header rules expected from Security Guild · Authority Core (due 2025-12-11 per sprint action tracker).
## Determinism Checklist
- [ ] Hash any inbound tables/examples and note source/approver.
- [ ] Keep examples offline-friendly and deterministic (fixed seeds, pinned versions, stable ordering).
- [ ] Record version/date of source specs when added.

2
docs/security/authority-threat-model.md
View File

@@ -2,6 +2,8 @@
> Prepared by Security Guild — 2025-10-12. Scope covers Authority host, Standard plug-in, CLI, bootstrap workflow, and offline revocation distribution.
> **Related:** For implementation details, see [Authority Architecture](../modules/authority/architecture.md).
## 1. Scope & Method
- Methodology: STRIDE applied to primary Authority surfaces (token issuance, bootstrap, revocation, operator tooling, plug-in extensibility).

45
docs/security/crypto-profile-configuration.md
View File

@@ -57,14 +57,43 @@ How to pick regional crypto profiles, choose between free/paid providers, and en
- OpenSSL GOST remote signer (OSS baseline) in `docs/security/openssl-gost-remote.md`.
## Simulation guidance
- Default simulator: `ops/crypto/sim-crypto-service` + provider `sim.crypto.remote` (see `docs/security/crypto-simulation-services.md`).
- Use the simulator to close sprints until certified evidence is available; keep "non-certified" labels in RootPack manifests.
- Quick simulation steps:
1) `docker build -t sim-crypto -f ops/crypto/sim-crypto-service/Dockerfile ops/crypto/sim-crypto-service`
2) `docker run --rm -p 8080:8080 sim-crypto`
3) Set `STELLAOPS_CRYPTO_ENABLE_SIM=1` and `STELLAOPS_CRYPTO_SIM_URL=http://localhost:8080`
4) Keep `sim.crypto.remote` first in `PreferredProviders` for the target profile.
5) Optional smoke harness (no VSTest): `dotnet run --project ops/crypto/sim-crypto-smoke/SimCryptoSmoke.csproj -c Release` with `SIM_PROFILE=ru-free|ru-paid|sm|eidas|fips|kcmvp|pq` and optional `SIM_MESSAGE`/`SIM_ALGORITHMS`.
Use simulation paths when licensed hardware or certified modules are unavailable. They keep the registry/profile contracts stable while waiting for customer licenses (CryptoPro), QSCD devices (eIDAS), KCMVP modules, or SM PKCS#11 tokens.
### Unified simulator (sim-crypto-service)
- **Location:** `ops/crypto/sim-crypto-service/`
- **Provider ID:** `sim.crypto.remote`
- **Algorithms covered:**
- GOST: `GOST12-256`, `GOST12-512`, `ru.magma.sim`, `ru.kuznyechik.sim` (deterministic HMAC-SHA256)
- SM: `SM2`, `sm.sim`, `sm2.sim` (deterministic HMAC-SHA256)
- PQ: `DILITHIUM3`, `FALCON512`, `pq.sim` (deterministic HMAC-SHA256)
- FIPS/eIDAS/KCMVP/world: `ES256`, `ES384`, `ES512`, `fips.sim`, `eidas.sim`, `kcmvp.sim`, `world.sim` (ECDSA P-256 with static key)
- The `SimRemoteProviderOptions.Algorithms` default list includes the IDs above; extend if you add new aliases.
### Quick simulation steps
1. Build and run:
```bash
docker build -t sim-crypto -f ops/crypto/sim-crypto-service/Dockerfile ops/crypto/sim-crypto-service
docker run --rm -p 8080:8080 sim-crypto
```
2. Configure environment:
- Set `STELLAOPS_CRYPTO_ENABLE_SIM=1` to append `sim.crypto.remote` to registry ordering.
- Point the client: `STELLAOPS_CRYPTO_SIM_URL=http://localhost:8080` or bind `StellaOps:Crypto:Sim:BaseAddress`.
- Keep `sim.crypto.remote` first in `PreferredProviders` for the target profile.
3. Quick check (curl):
```bash
curl -s -X POST http://localhost:8080/sign -d '{"message":"stellaops-sim-check","algorithm":"SM2"}'
```
4. Smoke harnesses (no VSTest):
- **PowerShell:** `ops/crypto/run-sim-smoke.ps1` (args: `-BaseUrl http://localhost:5000 -SimProfile sm|ru-free|ru-paid|eidas|fips|kcmvp|pq`)
- **Headless:** `dotnet run --project ops/crypto/sim-crypto-smoke/SimCryptoSmoke.csproj -c Release` with `SIM_PROFILE=ru-free|ru-paid|sm|eidas|fips|kcmvp|pq` and optional `SIM_MESSAGE`/`SIM_ALGORITHMS=SM2,pq.sim,ES256`.
Use the simulator to close sprints until certified evidence is available; keep "non-certified" labels in RootPack manifests.
## Evidence expectations
- JWKS export from Authority/Signer for the active profile.

59
docs/security/crypto-simulation-services.md
View File

@@ -1,59 +0,0 @@
# Crypto Simulation Services · 2025-12-11
Use these simulation paths when licensed hardware or certified modules are unavailable. They let us keep the registry/profile contracts stable while we wait for customer licenses (CryptoPro), QSCD devices (eIDAS), KCMVP modules, or SM PKCS#11 tokens.
## Unified simulator (sim-crypto-service)
- Location: `ops/crypto/sim-crypto-service/`
- Provider ID: `sim.crypto.remote`
- Algorithms covered:
- GOST: `GOST12-256`, `GOST12-512`, `ru.magma.sim`, `ru.kuznyechik.sim` (deterministic HMAC-SHA256)
- SM: `SM2`, `sm.sim`, `sm2.sim` (deterministic HMAC-SHA256)
- PQ: `DILITHIUM3`, `FALCON512`, `pq.sim` (deterministic HMAC-SHA256)
- FIPS/eIDAS/KCMVP/world: `ES256`, `ES384`, `ES512`, `fips.sim`, `eidas.sim`, `kcmvp.sim`, `world.sim` (ECDSA P-256 with static key)
- Run:
```bash
docker build -t sim-crypto -f ops/crypto/sim-crypto-service/Dockerfile ops/crypto/sim-crypto-service
docker run --rm -p 8080:8080 sim-crypto
curl -s -X POST http://localhost:8080/sign -d '{"message":"hello","algorithm":"SM2"}'
```
- Wire:
- Set `STELLAOPS_CRYPTO_ENABLE_SIM=1` to append `sim.crypto.remote` to registry ordering.
- Point the client: `STELLAOPS_CRYPTO_SIM_URL=http://<host>:8080` or bind `StellaOps:Crypto:Sim:BaseAddress`.
- The `SimRemoteProviderOptions.Algorithms` default list already includes the IDs above; extend if you add new aliases.
- Quick check:
```bash
curl -s -X POST http://localhost:8080/sign -d '{"message":"stellaops-sim-check","algorithm":"SM2"}'
```
- Scripted smoke (no VSTest): `scripts/crypto/run-sim-smoke.ps1` (args: `-BaseUrl http://localhost:5000 -SimProfile sm|ru-free|ru-paid|eidas|fips|kcmvp|pq`).
- Headless smoke harness (no VSTest): `dotnet run --project ops/crypto/sim-crypto-smoke/SimCryptoSmoke.csproj` (env: `STELLAOPS_CRYPTO_SIM_URL`, optional `SIM_ALGORITHMS=SM2,pq.sim,ES256`).
## Regional notes
- **RU (GOST)**: OSS remote signer available at `docs/security/openssl-gost-remote.md`. Licensed CryptoPro path is Linux-only via `ops/cryptopro/linux-csp-service` (customer debs, `CRYPTOPRO_ACCEPT_EULA=1`); use the simulator above when licensing is unavailable.
- **CN (SM)**: Hardware/PKCS#11 bring-up in `docs/security/sm-hardware-simulation.md`. Legacy SM-only simulator is retired; use `sim-crypto-service` for SM2 tests.
- **FIPS / eIDAS / KCMVP**: Hardware/QSCD runbook in `docs/security/fips-eidas-kcmvp-validation.md`. Until certified modules arrive, rely on the simulator above and keep profiles labeled “non-certified.”
- **PQ**: Built-in `pq.soft` remains the baseline; the simulator is available for integration tests that expect a remote signer.
## Config snippet (example)
```json
{
"StellaOps": {
"Crypto": {
"Registry": {
"ActiveProfile": "sm",
"PreferredProviders": [ "sim.crypto.remote", "cn.sm.soft" ]
},
"Sim": {
"BaseAddress": "http://localhost:8080"
}
}
}
}
```
## Evidence to capture
- JWKS export showing `sim.crypto.remote` keys.
- `CryptoProviderMetrics` with the simulated provider ID.
- Sample signatures/hashes from fixed message `stellaops-sim-vector`.
## Status
- Simulation coverage exists for all regions; real licensing/hardware remains customer-supplied. Use this doc to unblock sprint closures until certified evidence arrives.

2
docs/security/pq-provider-options.md
View File

@@ -71,7 +71,7 @@ Last updated: 2025-11-27 · Owners: Security Guild · Scanner Guild · Policy Gu
1) Implement provider classes under `StellaOps.Cryptography.Providers.Pq` with oqs bindings.
2) Wire registry config parsing for `Type=PostQuantum` with fields above.
3) Add DSSE signing option plumbing in Scanner/Policy/Attestor hosts using `SigningProvider` override.
4) Add env-gated tests to `scripts/crypto/run-rootpack-ru-tests.sh` (skip if oqs libs missing).
4) Add env-gated tests to `ops/crypto/run-rootpack-ru-tests.sh` (skip if oqs libs missing).
5) Document operator guidance in `docs/dev/crypto.md` and RootPack notes once providers are verified.
## Risks / mitigations

11
docs/security/redaction-and-privacy.md
View File

@@ -1,11 +0,0 @@
# Redaction and Privacy
- Pending telemetry privacy controls + opt-in debug flow.
## Pending Inputs
- Telemetry privacy controls + opt-in debug flow from Security Guild (due 2025-12-11 per sprint action tracker).
## Determinism Checklist
- [ ] Hash any sample configs/payloads and track source/approver.
- [ ] Keep guidance offline-friendly; avoid live endpoints in examples.
- [ ] Use deterministic ordering and pinned versions in any sample policies or logs.

4
docs/security/rootpack_ru_crypto_fork.md
View File

@@ -13,7 +13,7 @@
## How we consume it
- `src/__Libraries/StellaOps.Cryptography.Plugin.CryptoPro` now project-references the fork (removed `IT.GostCryptography` nuget).
- Runtime still Windows-only; plugin uses CSP (`CspParameters`) for key material when available.
- Tests are opt-in and Windows/CSP only: set `STELLAOPS_CRYPTO_PRO_ENABLED=1` and run `scripts/crypto/run-cryptopro-tests.ps1`.
- Tests are opt-in and Windows/CSP only: set `STELLAOPS_CRYPTO_PRO_ENABLED=1` and run `ops/crypto/run-cryptopro-tests.ps1`.
## How to sync the fork
- Track the pinned upstream commit in `src/__Libraries/StellaOps.Cryptography.Plugin.CryptoPro/third_party/AlexMAS.GostCryptography/STELLA_NOTES.md` (currently `31413f6`).
@@ -27,7 +27,7 @@
## Build & test quickstart (Windows runner with CryptoPro CSP installed)
```powershell
dotnet build src/__Libraries/StellaOps.Cryptography.Plugin.CryptoPro/StellaOps.Cryptography.Plugin.CryptoPro.csproj -c Release
scripts/crypto/run-cryptopro-tests.ps1 -Configuration Release
ops/crypto/run-cryptopro-tests.ps1 -Configuration Release
```
### CI (opt-in)

12
docs/security/rootpack_ru_package.md
View File

@@ -21,9 +21,9 @@ This guide describes the reproducible process for assembling the sovereign crypt
```bash
# from repository root
scripts/crypto/package-rootpack-ru.sh
ops/crypto/package-rootpack-ru.sh
# optionally specify destination
scripts/crypto/package-rootpack-ru.sh /tmp/rootpack_ru_$(date -u +%Y%m%dT%H%M%SZ)
ops/crypto/package-rootpack-ru.sh /tmp/rootpack_ru_$(date -u +%Y%m%dT%H%M%SZ)
```
The script performs the following steps:
@@ -45,11 +45,11 @@ cp src/__Libraries/StellaOps.Cryptography.Plugin.CryptoPro/third_party/AlexMAS.G
## 3. Attach deterministic test evidence
After running `scripts/crypto/package-rootpack-ru.sh`, execute the deterministic harness to capture logs:
After running `ops/crypto/package-rootpack-ru.sh`, execute the deterministic harness to capture logs:
```bash
scripts/crypto/run-rootpack-ru-tests.sh
# or specify ROOTPACK_LOG_DIR=/tmp/rootpack_ru_tests scripts/crypto/run-rootpack-ru-tests.sh
ops/crypto/run-rootpack-ru-tests.sh
# or specify ROOTPACK_LOG_DIR=/tmp/rootpack_ru_tests ops/crypto/run-rootpack-ru-tests.sh
```
Copy the resulting `logs/rootpack_ru_<timestamp>/` directory into the bundle before distributing it (or store it alongside the tarball in your evidence store).
@@ -97,7 +97,7 @@ Ship the CLI binary inside the RootPack so operators in sealed environments can
The bundle and scripts above assume several pieces of functionality that have not landed yet:
- **Integration tests:** `scripts/crypto/run-rootpack-ru-tests.sh` exercises only SHA/Ed25519 paths because CryptoPro/PKCS#11 integration tests are still TODO.
- **Integration tests:** `ops/crypto/run-rootpack-ru-tests.sh` exercises only SHA/Ed25519 paths because CryptoPro/PKCS#11 integration tests are still TODO.
- **Symmetric GOST:** RootPack artifacts ship only signing plug-ins; Magma/Kuznyechik support for exports/data-at-rest is pending.
These gaps are being tracked in Sprint 514 (SEC-CRYPTO backlog). This guide will be updated once the missing work is delivered.

4
docs/security/rootpack_ru_validation.md
View File

@@ -6,7 +6,7 @@ This runbook documents the repeatable steps for validating the Russian sovereign
## 1. Deterministic Test Harness
1. Run `scripts/crypto/run-rootpack-ru-tests.sh` (optional `ROOTPACK_LOG_DIR=/tmp/rootpack_ru_logs` to override the output path). The script executes:
1. Run `ops/crypto/run-rootpack-ru-tests.sh` (optional `ROOTPACK_LOG_DIR=/tmp/rootpack_ru_logs` to override the output path). The script executes:
- `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/StellaOps.Cryptography.Tests.csproj`
- `src/Scanner/__Tests/StellaOps.Scanner.Worker.Tests/StellaOps.Scanner.Worker.Tests.csproj`
- `src/Scanner/__Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests.csproj`
@@ -30,7 +30,7 @@ This runbook documents the repeatable steps for validating the Russian sovereign
2. Configure the `OpenSsl` section (PEM path plus `PrivateKeyPassphraseEnvVar`), keep `StellaOps:Crypto:Registry:ActiveProfile=ru-offline`, and restart the services.
3. Execute a signing workflow and confirm `CryptoProviderMetrics` records `ru.openssl.gost` activity. Linux nodes should no longer attempt to load `ru.cryptopro.csp`.
4. **2025-12-07 validation evidence (Linux, containerised OpenSSL GOST engine):**
- Ran `scripts/crypto/validate-openssl-gost.sh` (uses `rnix/openssl-gost:latest`) to generate deterministic digests and two md_gost12_256 signatures over a fixed message. Output folder: `logs/openssl_gost_validation_<timestamp>/`.
- Ran `ops/crypto/validate-openssl-gost.sh` (uses `rnix/openssl-gost:latest`) to generate deterministic digests and two md_gost12_256 signatures over a fixed message. Output folder: `logs/openssl_gost_validation_<timestamp>/`.
- Summary from the run at `20251207T220926Z`:
- Message SHA256: `e858745af13089d06e74022a75abfee7390aefe7635b15c80fe7d038f58ae6c6`
- md_gost12_256 digest: `01ddd6399e694bb23227925cb6b12e8c25f2f1303644ffbd267da8a68554a2cb`

2
docs/security/scopes-and-roles.md
View File

@@ -1,5 +1,7 @@
# Scopes and Roles
> **Canonical Reference:** For the complete, authoritative list of 90+ scopes with role bundles and configuration examples, see [authority-scopes.md](./authority-scopes.md).
This document defines the **scope taxonomy** and how scopes map to roles across StellaOps. It is intentionally cross-cutting and does not attempt to list every module-specific scope; module dossiers and gateway contracts are the source of truth for per-surface requirements.
## Terms