R3ap3r/aurora-dockside
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add secure pac module packages

Browse Source
This commit is contained in:
reaper
2026-08-14 17:43:16 -05:00
parent afce94a0a8
commit 9a8476507b
8 changed files with 182 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ALPHA24_COMPLETION_REPORT.md
+9 -6
View File
@@ -11,7 +11,10 @@
- Application packages are discovered and installed into Aurora's Electron user-data `modules` directory.
- The module registry is invalidated after install, update, and uninstall operations.
- Package manifests are validated for identity, version, category, dependencies, conflicts, settings, Core/API compatibility, project contributions, and safe relative entry paths.
- Installation rejects symbolic links and paths that could escape the package or module destination.
- Native `.pac` files are ZIP-compressed Aurora packages with `manifest.json` at archive root.
- A `.pac` placed beside the AppImage or in its `modules` folder is discovered automatically and appears in the Modules screen.
- `.pac` inspection rejects encrypted entries, symbolic links, path traversal, absolute/drive paths, excessive entry counts, and expanded archives larger than 256 MiB before extraction.
- Installation uses staging plus rollback-safe replacement, so a failed update preserves the currently installed module.
- Application choices in New Project come only from the installed-module registry.
- Project actions and metadata summaries are declarative module contributions. Core no longer contains WordPress-specific admin or multisite presentation.
- The `moduleMetadata` capability is the versioned bridge used by trusted module lifecycle hooks.
@@ -41,13 +44,14 @@ npm run build
npx electron-builder --linux AppImage
```
Automated result: 6 test files and 23 tests passed. Coverage includes:
Automated result: 6 test files and 26 tests passed. Coverage includes:
- Empty registry
- Available local packages
- Valid installation and registry refresh
- Invalid and incompatible manifest rejection
- Unsafe package path and symbolic-link rejection
- `.pac` discovery, installation, traversal rejection, and archive symlink rejection
- Package update
- Registry refresh after uninstall
- Preservation of source packages and existing project data
@@ -67,18 +71,17 @@ Live project smoke result for project `24`:
## Artifacts
- Core AppImage: `/home/reaper/Documents/Codex/aurora/dist/final-alpha24/aurora-dockside-2.0.0-alpha.24.AppImage`
- WordPress package archive: `/home/reaper/Documents/Codex/aurora/dist/final-alpha24/aurora-module-wordpress-1.2.0.tar.gz`
- Directly installable WordPress package: `/home/reaper/Documents/Codex/aurora/dist/final-alpha24/aurora-module-wordpress-1.2.0.pac`
- Directly installable unpacked WordPress package: `/home/reaper/Documents/Codex/aurora/packages/aurora-module-wordpress`
SHA-256:
```text
fe700b5528ad7ddcdae43ced5651801370b2b09f8ed711fb447179281b6a9257 aurora-dockside-2.0.0-alpha.24.AppImage
942068c4eeb9b638f8aa6041dc8e5c15cec95fa6901fa24ed197221469ce37e9 aurora-module-wordpress-1.2.0.tar.gz
1964de899632f7dca86b5ee6485d5c2bc8dc0cffcc7a9de4479ea7eef25e9e76 aurora-dockside-2.0.0-alpha.24.AppImage
d2165af4b75ab888c6d35a750a449205123866231ba5e98e1cbe9bcaa8738f46 aurora-module-wordpress-1.2.0.pac
```
## Known limitations
- The module picker installs unpacked package directories. Extract the `.tar.gz` before selecting it in **Install from folder**.
- Clean-registry install/remove behavior was exercised through the real registry implementation in automated temporary-directory tests. The live GUI smoke used the already installed local WordPress package and project `24`.
- AppImage systems without working FUSE can use `--appimage-extract` and launch `squashfs-root/AppRun --no-sandbox`.