You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parent roadmap: #141. Optional extension after the eleven core phases; it does not block the local-history acceptance gate #150.
Objective
Offer an opt-in, encrypted history view across two or more Atenea SSH controller installations.
Scope
Keep the initial controller-local encrypted history from #145 as the source of record. Add explicit enrollment of each controller, authenticated device membership and end-to-end encrypted exchange of selected audit records. Define the sync transport and its trust boundary before implementation; no published dashboard endpoint or default cloud account is assumed. Keep key material in native protected stores with documented enrollment, new-device approval, recovery, rotation, revocation and deletion behavior. Revocation protects future exchange; it cannot erase ciphertext or plaintext already obtained by a former member.
Deduplicate by immutable controller/event IDs and preserve original target/account identity, request UUID, timestamp, controller provenance, visibility, permission and evidence level. Different controller clocks cannot create a guaranteed global order. Offline changes, replays, duplicate delivery, conflicting deletion requests and interrupted sync must converge without rewriting the original audit event or authorizing a new SSH dispatch. Deletion needs explicit local and synchronized tombstone semantics, backup behavior and remote transcript disclosure. Synchronization is observation only: it never sends prompts for execution or grants SSH/credential permissions on a new controller.
The SSH config, private keys, stored SSH passwords and key passphrases stay local in this phase. A synced target reference that is absent or resolves differently on another controller is displayed as history with source provenance, not treated as a ready local connection. Share prompt/result plaintext only after authorized decryption in the receiving controller's UI; never put raw prompts, passwords or keys into transport logs, notifications or GitHub evidence.
Required design gate
Before implementation, review a concrete versioned protocol specifying transport/provider and metadata exposure, enrollment authority, vetted encryption/authentication libraries, per-origin authenticated event provenance, membership/key epochs, recovery and tombstone retention. Do not invent custom cryptography or treat possession of a shared encryption key as proof of which controller authored an event. This issue remains design-pending until these choices and an executable fault-test plan are recorded; split independently deliverable transport work into linked issues if needed.
Use an explicit export schema and user-selected records/fields. Config/trust snapshots must be filtered; excluding the raw SSH config file alone is insufficient. Explain that selected prompts/results may themselves contain user-entered sensitive text. Never export vault values, private keys, operational recovery receipts or executable activation references. Preserve audit correlation as inert metadata, isolated from the receiving controller's dispatch/admission/reconciliation stores. Imported evidence is attributed to its source, not newly verified on the receiving PC. Importing records must not trigger #155 task alerts.
Revocation takes effect at an authoritative membership/key-epoch update. New publications require current membership verification and keys excluding the revoked member; offline or stale-epoch publication waits rather than weakening that rule. Specify how in-flight old-epoch data is rejected or classified as pre-revocation exposure. Previously accessible content and copies remain outside the future-confidentiality guarantee. A cloned/restored controller must not silently become a second writer under the same origin identity; require controlled identity recovery or fresh enrollment.
Distinguish removing a local replica from requesting synchronized deletion. Authenticate deletion authority and distribute durable tombstones to prevent replay resurrection; document the retention horizon and mandatory full resync/re-enrollment for replicas older than it. Deletion cannot promise erasure from offline/revoked devices, external backups or provider transcripts. Minimal non-replay receipts in source operational storage remain governed by #145 and are never deleted by a received tombstone.
Acceptance criteria
Two enrolled controllers show the same selected historical events after offline/reconnect cycles, with source controller and evidence coverage intact.
Duplicates, clock skew, interrupted transfers, deleted events and revoked members produce deterministic, documented results without remote re-dispatch.
After authoritative revocation, newly published records use the new membership/key epoch; stale offline publishers cannot publish under an obsolete epoch. Previously shared data, in-flight exposure and key-loss/recovery limits are explicit.
Forged origin IDs, cloned backups, stale tombstone replay and imported operational-looking records cannot impersonate another origin, revive deleted payloads, create task alerts or alter execution/recovery state.
Local-only mode remains available and its data is not uploaded without opt-in; local SSH config, keys and vault credentials are not copied.
Validation and evidence level
Protocol and crypto tests, two native controller installations, offline/concurrent fault tests, backup/recovery tests and synthetic sensitive-data scans. Exact encryption/key/protocol versions and observed UI state are required.
Dependencies and risks
Depends on #145 and the core acceptance #150. It also needs the verified controller identity and packaging from #151/#148. Any shared transport or account system must be designed and reviewed as part of this issue before coding.
Out of scope
Automatic sync of raw OpenSSH config, private keys or native-vault secrets; remote execution through synced history; a claim that revocation deletes copies already held by a device.
Delivery boundary
One primary implementation issue with its own design review and validation. Split independent transport or platform work into follow-up issues if needed; do not enlarge the already scoped #145/#150 PRs. Parent #141 can close on its eleven core phases while this optional extension remains open. No private prompts or credential material in public evidence.
Parent roadmap: #141. Optional extension after the eleven core phases; it does not block the local-history acceptance gate #150.
Objective
Offer an opt-in, encrypted history view across two or more Atenea SSH controller installations.
Scope
Keep the initial controller-local encrypted history from #145 as the source of record. Add explicit enrollment of each controller, authenticated device membership and end-to-end encrypted exchange of selected audit records. Define the sync transport and its trust boundary before implementation; no published dashboard endpoint or default cloud account is assumed. Keep key material in native protected stores with documented enrollment, new-device approval, recovery, rotation, revocation and deletion behavior. Revocation protects future exchange; it cannot erase ciphertext or plaintext already obtained by a former member.
Deduplicate by immutable controller/event IDs and preserve original target/account identity, request UUID, timestamp, controller provenance, visibility, permission and evidence level. Different controller clocks cannot create a guaranteed global order. Offline changes, replays, duplicate delivery, conflicting deletion requests and interrupted sync must converge without rewriting the original audit event or authorizing a new SSH dispatch. Deletion needs explicit local and synchronized tombstone semantics, backup behavior and remote transcript disclosure. Synchronization is observation only: it never sends prompts for execution or grants SSH/credential permissions on a new controller.
The SSH config, private keys, stored SSH passwords and key passphrases stay local in this phase. A synced target reference that is absent or resolves differently on another controller is displayed as history with source provenance, not treated as a ready local connection. Share prompt/result plaintext only after authorized decryption in the receiving controller's UI; never put raw prompts, passwords or keys into transport logs, notifications or GitHub evidence.
Required design gate
Before implementation, review a concrete versioned protocol specifying transport/provider and metadata exposure, enrollment authority, vetted encryption/authentication libraries, per-origin authenticated event provenance, membership/key epochs, recovery and tombstone retention. Do not invent custom cryptography or treat possession of a shared encryption key as proof of which controller authored an event. This issue remains design-pending until these choices and an executable fault-test plan are recorded; split independently deliverable transport work into linked issues if needed.
Use an explicit export schema and user-selected records/fields. Config/trust snapshots must be filtered; excluding the raw SSH config file alone is insufficient. Explain that selected prompts/results may themselves contain user-entered sensitive text. Never export vault values, private keys, operational recovery receipts or executable activation references. Preserve audit correlation as inert metadata, isolated from the receiving controller's dispatch/admission/reconciliation stores. Imported evidence is attributed to its source, not newly verified on the receiving PC. Importing records must not trigger #155 task alerts.
Revocation takes effect at an authoritative membership/key-epoch update. New publications require current membership verification and keys excluding the revoked member; offline or stale-epoch publication waits rather than weakening that rule. Specify how in-flight old-epoch data is rejected or classified as pre-revocation exposure. Previously accessible content and copies remain outside the future-confidentiality guarantee. A cloned/restored controller must not silently become a second writer under the same origin identity; require controlled identity recovery or fresh enrollment.
Distinguish removing a local replica from requesting synchronized deletion. Authenticate deletion authority and distribute durable tombstones to prevent replay resurrection; document the retention horizon and mandatory full resync/re-enrollment for replicas older than it. Deletion cannot promise erasure from offline/revoked devices, external backups or provider transcripts. Minimal non-replay receipts in source operational storage remain governed by #145 and are never deleted by a received tombstone.
Acceptance criteria
Validation and evidence level
Protocol and crypto tests, two native controller installations, offline/concurrent fault tests, backup/recovery tests and synthetic sensitive-data scans. Exact encryption/key/protocol versions and observed UI state are required.
Dependencies and risks
Depends on #145 and the core acceptance #150. It also needs the verified controller identity and packaging from #151/#148. Any shared transport or account system must be designed and reviewed as part of this issue before coding.
Out of scope
Automatic sync of raw OpenSSH config, private keys or native-vault secrets; remote execution through synced history; a claim that revocation deletes copies already held by a device.
Delivery boundary
One primary implementation issue with its own design review and validation. Split independent transport or platform work into follow-up issues if needed; do not enlarge the already scoped #145/#150 PRs. Parent #141 can close on its eleven core phases while this optional extension remains open. No private prompts or credential material in public evidence.