Vulnerability handling

Reporting

Private reports first: sensitive issues go to the maintainer team by email rather than a public issue. Include affected packages, versions, and reproduction or PoC details.
Public issues are fine for hardening suggestions and non-sensitive bugs ("this config file is world-readable").
Upstream-first: most vulnerabilities arrive through upstream (a CVE in a library, an app bug fixed upstream). Track those through the normal update cycle; no separate Parch process is needed for packages that track upstream closely.

Triage and response

report → confirm impact (versions, vectors) → decide: fix fast or fix upstream
       → prepare fixed package (patch or version bump)
       → test in chroot → publish to world with a security update subject
       → public note if users must act

Fixes ship as normal package updates with pkgrel+1; the commit and submission subject reference the CVE.
If exploitation requires local access vs remote, say so in the note; it changes user urgency.
Users on rolling systems get the fix via pacman -Syu; no separate channel exists, so the update must be complete before the advisory.
For vulnerabilities in world's build tooling or repository infrastructure, treat as critical and coordinate with the core team privately.

Shipping the note

Security notes appear in the release notes of the next ISO build and as a forum post when user action matters. A good note states: what was wrong, which versions are affected, what the fix is, and what users should do (usually "update"; occasionally "revoke a key" or "check a config").

Hardening backlogs

Non-urgent security work is tracked in issue trackers with the security label: repository signing, ISO signing, CI hardening, and sandboxing improvements live there today (see the honest status table in the security overview). Backlog items are real work with owners, not wishes: each has a linked design sketch before it is promised.