dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 15 Pull Requests Actions Packages Projects Releases Wiki Activity

Transport bundle signing: key/trust/rotation decisions; pull + differential bundles (#45 follow-up) #110

New Issue
Closed
opened 2026-11-09 17:44:18 -05:00 by dohertj2 · 2 comments
dohertj2 commented 2026-11-09 17:44:18 -05:00
Owner
Copy Link
Copy Source

Follow-up from ScadaBridge#45. Bundle signing landed on main (detached ECDSA P-256 manifest.sig over manifest.json, off by default, RequireSignedBundles opt-in, format version unchanged; pre-signing bundles checked in as fixtures and proven to still import). Cluster-to-cluster pull and differential bundles are written up without code in docs/plans/2026-11-09-transport-pull-and-differential-addendum.md.

Decisions needed:

  1. Signing keys: one per environment or one per organisation?
  2. Trust distribution/rotation: keep hand-edited ScadaBridge:Transport:Signing:TrustedKeys, or a config-DB trust list editable in the Admin UI with expiry/revocation?
  3. Default RequireSignedBundles to on at the production boundary once every exporting cluster signs?
  4. Should the default key source read the Secrets store directly instead of via ${secret:} config expansion?
  5. Pull: is any cross-environment network path acceptable to change control, and which machine identity would the pull use? (Recommendation: no code until decided; CLI export→import already covers it.)
  6. Differential bundles: are deletions in scope? (Recommendation: stay deferred; import already skips identical artifacts.)
Follow-up from ScadaBridge#45. Bundle signing landed on main (detached ECDSA P-256 `manifest.sig` over `manifest.json`, off by default, `RequireSignedBundles` opt-in, format version unchanged; pre-signing bundles checked in as fixtures and proven to still import). Cluster-to-cluster pull and differential bundles are written up without code in `docs/plans/2026-11-09-transport-pull-and-differential-addendum.md`. Decisions needed: 1. Signing keys: one per environment or one per organisation? 2. Trust distribution/rotation: keep hand-edited `ScadaBridge:Transport:Signing:TrustedKeys`, or a config-DB trust list editable in the Admin UI with expiry/revocation? 3. Default `RequireSignedBundles` to on at the production boundary once every exporting cluster signs? 4. Should the default key source read the Secrets store directly instead of via `${secret:}` config expansion? 5. Pull: is any cross-environment network path acceptable to change control, and which machine identity would the pull use? (Recommendation: no code until decided; CLI export→import already covers it.) 6. Differential bundles: are deletions in scope? (Recommendation: stay deferred; import already skips identical artifacts.)
dohertj2 added the type:followuppriority:p3 labels 2026-11-09 17:44:18 -05:00
dohertj2 commented 2026-11-09 22:13:26 -05:00
Author
Owner
Copy Link
Copy Source

Owner decision 2026-11-09: one signing key per environment, held in the Secrets store and read via ${secret:}; keep the hand-edited ScadaBridge:Transport:Signing:TrustedKeys (no Admin UI trust list yet); default RequireSignedBundles on at the production boundary once every exporting cluster signs; no cluster-to-cluster pull (CLI export→import covers it); differential deletions stay deferred.

**Owner decision 2026-11-09:** **one signing key per environment**, held in the Secrets store and read via ${secret:}; keep the hand-edited `ScadaBridge:Transport:Signing:TrustedKeys` (no Admin UI trust list yet); default `RequireSignedBundles` on at the production boundary once every exporting cluster signs; **no cluster-to-cluster pull** (CLI export→import covers it); differential deletions stay deferred.
dohertj2 commented 2026-11-09 22:50:25 -05:00
Author
Owner
Copy Link
Copy Source

Implemented in 559e02f5 (main).

  • Decision 1/2: no code change; one key per environment, hand-edited TrustedKeys. Runbook: docs/operations/bundle-signing-runbook.md (openssl keygen, store as secret, distribute public key, rotation, RequireSignedBundles flip order).
  • Decision 3: new Signing:ProductionBoundary flag (default off). While true and RequireSignedBundles is false: startup WARNING + Degraded bundle-signing-policy /health/ready entry (HTTP 200). Code default of RequireSignedBundles unchanged.
  • Decision 4: ${secret:} PrivateKey verified end to end (TransportSigningSecretExpansionTests: expand -> bind -> validate -> sign -> Verified); validation messages and the signature entry never contain key material (tests).
  • Decisions 5/6: pull marked decided-not-to-build, differential deletions deferred, in the addendum and Component-Transport.md.

Evidence: build 0 warnings; Transport.Tests 228+, Transport.IntegrationTests 151, Host.Tests 668 pass (plus 3 new health-check tests); mutation-proved (advisory condition, warning log, key source, health status each fail their tests when broken).

Implemented in 559e02f5 (main). - Decision 1/2: no code change; one key per environment, hand-edited TrustedKeys. Runbook: docs/operations/bundle-signing-runbook.md (openssl keygen, store as secret, distribute public key, rotation, RequireSignedBundles flip order). - Decision 3: new `Signing:ProductionBoundary` flag (default off). While true and RequireSignedBundles is false: startup WARNING + Degraded `bundle-signing-policy` /health/ready entry (HTTP 200). Code default of RequireSignedBundles unchanged. - Decision 4: `${secret:}` PrivateKey verified end to end (TransportSigningSecretExpansionTests: expand -> bind -> validate -> sign -> Verified); validation messages and the signature entry never contain key material (tests). - Decisions 5/6: pull marked decided-not-to-build, differential deletions deferred, in the addendum and Component-Transport.md. Evidence: build 0 warnings; Transport.Tests 228+, Transport.IntegrationTests 151, Host.Tests 668 pass (plus 3 new health-check tests); mutation-proved (advisory condition, warning log, key source, health status each fail their tests when broken).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Blocked by dependency or external hold
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 type:bug
Defect in shipped behaviour
 type:debt
Technical debt / hygiene
 type:deploy-gate
Rollout/deploy/migration step not yet done on an environment
 type:docs
Documentation work
 type:feature
Feature implementation
 type:followup
Follow-up deferred from a plan, PR or gate
 type:infra
Infrastructure and scaffolding
 type:review-finding
Unfixed finding from an architecture/code review
 type:test
Test work
No Label priority:p3 type:followup
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/ScadaBridge#110
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?