Security model

Security via upgradeable packages.

The core model is simple: security state should be versioned, inspectable, upgradeable, and recoverable through packages. Manual hardening can still exist, but official posture belongs in package-owned policy, scripts, reports, and validation commands.

Controlled changes

Security changes should have package names, versions, changelogs, manifests and clear ownership.

Auditability

Reports, checksums, validation outputs and advisory records should be published where practical.

Recovery

Rollback notes, safe defaults and repair tools should be part of the release discipline.

Risk classes

Security pages should cover the real failure modes.

Package scripts Maintainer scripts must avoid destructive surprise behaviour.
Restore/import Archive extraction and database restore paths require explicit validation.
Local data Databases, backups, exports, sidecars and handoff files should use private permissions where practical.
Network behaviour Network features should be explicit and documented.
Browser/wallet High-trust workflows require clear user approval boundaries.
AEGIS actions Tool actions should be bounded, local-first, and user-authorised.
Current application-control boundary: the v1.0 converter audits firewall and AppArmor state but does not silently enable a universal firewall, create application profiles or containerise external software. Per-application isolation and outbound approval require a separately implemented and tested policy layer.
Advisories

Future disclosures belong in a public ledger.

Use the advisory page format whenever a security issue needs public disclosure.

SENTINEL-SA-YYYY-NNN
Affected package:
Fixed version:
Upgrade command:
Verification:
Practical guidance

Operational pages