Development
Contributing
Read the implementation, reproduce behavior in the disposable guest, and make focused changes with evidence.
On this page
psh is an experimental project. The most useful starting point is to understand a concrete behavior, reproduce it in the disposable guest, and make a focused change that preserves the security boundaries.
Find the source
The project is hosted at git.thc420.dev/ZetaReticuli/psh
. Read the repository’s AGENTS.md for development rules and use its checked-in .clang-format for project-owned C.
git clone https://git.thc420.dev/ZetaReticuli/psh.git
cd psh
Start with the design
Read the design paper , protocol boundaries , and paired authentication contract . These explain the invariants behind the implementation.
Changes should preserve independent broker authorization, bounded resource use, complete-pair identities, and the mandatory cryptographic policy. Keep project-owned C readable and explain non-obvious security invariants.
Reproduce inside the guest
All psh builds and tests run in the disposable QEMU VM. Do not run psh test binaries, privileged tests, account-management tests, or test listeners on the host.
tools/vm/vm.sh start
tools/vm/vm.sh wait
tools/vm/vm.sh sync
tools/vm/vm.sh run 'make -j2 all && make test'
Use the VM guide for prerequisites and the validation guide to choose focused suites. Runtime dependencies are pinned and vendored; builds must not silently switch to system crypto or YAML libraries.
Make results reviewable
Record the source revision, commands, environment, output, and limitations. Preserve logs in guest /work/results and copy them using the VM helper. A passing test or a dated historical result is evidence about the candidate that ran it, not a production-readiness claim.
Work on this website
This site is a separate, fully static Hugo project. Its documentation is a checked-in snapshot of the psh source. The website README explains local preview, production builds, documentation refreshes, and static hosting.