Controlled changes
Security changes should have package names, versions, changelogs, manifests, and clear ownership.
Security centre
Package-governed security for a local-first system.
SentinelOS treats security improvements as upgradeable package material: hardening, repairs, validation commands, safe defaults, reports, and rollback helpers.
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.
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 scriptsMaintainer scripts must avoid destructive surprise behavior.
Restore/importArchive extraction and database restore paths require explicit validation.
Local dataDatabases, backups, exports, sidecars, and handoff files should use private permissions where practical.
Network behaviorNetwork features should be explicit and documented.
Browser/walletHigh-trust workflows require clear user approval boundaries.
AEGIS actionsTool actions should be bounded, local-first, and user-authorised.
Advisories
Future disclosures belong in a public ledger.
Use the advisory page format for security notices once public builds exist.
SENTINEL-SA-YYYY-NNN
Affected package:
Fixed version:
Upgrade command:
Verification:v0.9.5 download publication