Security
This section is deliberately honest: it separates what Parch does today from what it should do. Security claims that outrun reality are themselves a vulnerability.
Status of record
| Area | Status | Where |
|---|---|---|
| Source verification in PKGBUILDs (sha256) | Practice | Dependency trust |
| Clean chroot builds | Practice | Build isolation |
| world/Void repositories | Real, unsigned | Repository infrastructure |
| Package/repo signing | Proposed | Signing |
| Automated ISO rebuilds in CI | Real | CI/CD |
| Reproducible builds end to end | Aspiration | Release artifacts |
| Vulnerability response process | Informal, documented here | Vulnerability handling |
The honest picture
Parch packages carry real sha256 checksums and are reviewed before entering
the repositories. The repositories themselves are served unsigned over
GitHub; users trust TLS and the repository account. ISOs ship with
md5sums.txt rather than GPG signatures. These are known gaps, not hidden
ones, and closing them (repo signing keys, signed sync databases, signed
ISOs) is the direction described in the linked pages.
Principles that apply everywhere
- Verify every source: checksums in PKGBUILDs,
validpgpkeyswhere upstream signs releases. - Build in isolation: clean chroots for packages, containers for ISOs.
- Least privilege in apps: polkit for privileged actions, never sudo-in-a-loop (see app security practices).
- Secrets never in repositories, logs, or screenshots.
- Report vulnerabilities privately first (how).
Continue in Security
Dependency trustVerifying sources, judging upstream, and managing supply-chain risk.Build isolationClean chroots, container builds, and secrets handling.Vulnerability handlingReporting, triage, and shipping security fixes on a rolling release.Release artifactsChecksums, verification, and the signing work that turns trust into proof.