Security model
Current installer safeguards, trust boundaries and gaps before public release.
The BSIS installer performs sensitive filesystem operations. The initial Rust prototype takes a deliberately narrow approach: it only writes a verified package into a new installation directory.
Not production-ready. These are safeguards in a proof of concept, not a complete security review. There is no Authenticode signing, trusted publisher verification, privileged Windows integration or hardened concurrent-filesystem threat model yet.
Implemented safeguards
| Area | Current behavior |
|---|---|
| Manifest | Strict schema version 1; unknown JSON fields are rejected |
| Paths | Rejects path traversal and invalid Windows destination names |
| Package contents | Explicit file list with sizes and SHA-256 hashes |
| Bundle integrity | Checks compressed payload digest; optional deep verification also hashes all embedded files against the manifest |
| Extraction | Verifies each extracted file while writing to a staging directory |
| Commit | Renames the completed stage to a new target after verification |
| Existing installs | Accepts a new or existing empty directory, but refuses to overwrite a nonempty target |
| Uninstall | Validates the receipt and hashes, including managed Uninstall.exe, before deleting tracked files |
| Verification | Read-only drift report, JSON output and failure exit code on mismatch |
| Source input | Rejects unsupported links and reparse points during packaging |
The prototype also caps manifest size, file count and total declared payload size. These limits are not a promise that every large package will work on every Windows system.
The verification CLI can identify missing, modified and unsafe tracked files without attempting an uninstall.
Deep bundle verification catches content that disagrees with the embedded manifest even if the outer compressed checksum has been recomputed. It does not authenticate an executable whose manifest and payload were both rewritten.
Checksums are not signatures
SHA-256 detects accidental corruption and unexpected file changes. It does not authenticate the source of a setup executable or prove that the publisher is trusted. Signing and verification must be designed and tested before production distribution.
Install vs. uninstall
During install, BSIS unpacks into a fresh directory beside the requested target and only moves it into position after extraction completes. If the destination already exists and is empty, the prototype temporarily moves it aside and attempts restoration if committing the staged installation fails. This reduces incomplete installations but is not a general-purpose transaction manager.
During uninstall, BSIS preserves files it did not install. If a tracked file or the installed Uninstall.exe has changed, a preflight check refuses to proceed. New installs include their own native Uninstall.exe. Windows executes a best-effort post-exit cleanup helper to remove the running uninstaller and, if empty, its folder. Apps & Features registration and repair are still missing.
Unimplemented protections and capabilities
- Secure administrator elevation and UAC workflows.
- Authenticode signing and publisher trust verification.
- Hardened handling of concurrent filesystem modifications or hostile local processes.
- Windows services, registry modifications, shortcuts and Apps & Features registration.
- Updates into existing directories, rollback, repair and recovery journals.
- Safe runtime plugin permissions or a documented privileged action protocol.
See Architecture and Roadmap for planned boundaries. Report security findings privately while the core remains in development.