All of Linxira's first-party software ships through the official signed repository [linxira]. The signatures are not decoration: mandatory verification on the pacman side, release-key rotation, and a PKGBUILD CI gate — three layers that together answer one question: how can you be sure that every package you install is the exact package the project published? This article lays out the full design.
First, what exactly are we defending against. A software repository is essentially "a remote database plus a pile of binaries": pacman reads the database to get the package list and checksum information, then downloads the matching .pkg.tar.zst from the server and installs it. Two attack points matter most in this chain:
Both attacks end the same way: your system installs binaries that are not what the project published — a modified kernel, a backdoored tool — and to pacman everything "looks" completely normal. On a desktop supercomputer, that hands the trust root of every compute result to the attacker. The signature system exists so that neither replacement can pass verification.
Why would repositories be the target rather than individual websites? Because a repository is a one-to-many distribution point: one tampering event affects every user who installs or updates from it — concentrated gain, amortized cost, the classic supply-chain attack model. Real-world supply-chain attacks (against software repositories and upstream dependencies alike) repeatedly demonstrate the right defense posture: not "trust that the server was never compromised", but "even if the server is compromised, tampering cannot pass verification". That is precisely what the signature system provides.
The [linxira] repository is configured as follows:
[linxira]
Server = https://linxira-os.github.io/linxira-packages/x86_64
SigLevel = Required DatabaseOptionalSigLevel = Required DatabaseOptional means: database signatures are mandatory, package signatures are optional but verified by default — the database (linxira.db) must pass signature verification, and packages must verify their signatures by default. Both checks are enforced on the pacman side; they do not depend on the user remembering to "verify", nor on whatever the download tool did. Even if a mirror or CDN is hijacked, pacman refuses to install as long as signature verification fails.
The only thing needed on the user side is a correct Server entry — and the system configures it automatically during install, so nothing needs to be added manually afterwards.
What users see on verification failure is an explicit refusal, not silent acceptance: a database or package whose signature does not match is rejected outright by pacman, with an error pointing at signature verification. For the ordinary user this means "a bad package slipped in mid-update" is intercepted up front — the problem surfaces before install, not after the system is damaged.
Signature verification depends on a trust anchor: pacman must trust "the key that signed these packages". Linxira's approach is to ship a linxira-keyring package: installing it completes key import and local trust — pacman automatically imports the release key and marks it trusted, with no manual key commands needed.
The key is not immutable: the release key was rotated on 2026-08-04. Rotation means that even if an old key leaks or needs retirement, new signatures take effect immediately and the old key is no longer trusted — the supply chain never runs with a "valid forever" liability.
One deliberate design choice: the key fingerprint is not published on the website. The rationale is that the trust anchor must come from the package you install, not from text on a web page — web pages can be impersonated or tampered with, whereas the linxira-keyring you install arrives verified by pacman. The first-trust path is: pacman-key --init initializes the local keyring → install linxira-keyring → the key is imported and locally trusted. This path keeps "who do I trust" in the software layer, not the information layer.
Rotation can also be understood on a timeline: keys issued before 2026-08-04 are no longer trusted after the rotation, and anything still signed with the old key fails verification. This turns "key trust" from a one-time permanent grant into a manageable, revocable lifecycle — the same maintenance philosophy Arch applies to its own keyring.
From the user's point of view, key maintenance is just another package update: when the keyring is rotated, linxira-keyring ships the new key and pacman picks it up through the same signed-repository flow described below — no manual key ceremonies, no fingerprint typing, no "is this website real" decisions.
The repository itself is generated and signed by the release process. Every release signs the database with repo-add:
repo-add --sign --key <fingerprint> linxira.db.tar.zst ./*.pkg.tar.zstThis command registers every .pkg.tar.zst in the current directory into linxira.db.tar.zst and signs the database with the release key; the database and packages are then deployed to GitHub Pages together. The whole flow mirrors how the official Arch repositories are maintained: the database signature guarantees "this package list is what the project published", and package signatures guarantee "every package in the list was built by the project".
Deploying to GitHub Pages carries a side benefit: distribution runs over static hosting, and with HTTPS, transport integrity is covered by TLS while content integrity is covered by signatures — two lines of defense, each responsible for its own segment, neither depending on the other. No matter which mirror or which moment a user pulls from, what they fetch and verify is the same signed content.
The mechanics are worth a sentence, because they explain what "signing the database" actually produces. The .tar.zst extension is not a zip of packages — it is the compressed repository database format pacman expects: an archive of metadata records (package names, versions, file lists, checksums) plus the .db.sig sidecar signature that --sign generates. pacman downloads the database, verifies the signature against the trusted release key, and only then trusts the package list inside it. The packages themselves each carry their own signature, verified at download time.
Signatures solve tampering in transit and at rest, but there is a further upstream question: where do the packages themselves come from? If a maintainer's PKGBUILD references an uncontrolled software source, then even with intact signatures, the package content may have been pulled from somewhere untrustworthy.
That is the job of check-boundaries.sh — the first gate in the linxira-packages CI: it validates PKGBUILD boundaries, including forbidding CachyOS / AUR / Seafoam repository references, forcing codeload / release-tarball sources, and verifying pinned commits and sha256 checksums. Any PKGBUILD change must pass it before it can be merged.
This layer answers the "source" question: most Linxira first-party packages use the codeload-commit pattern — source pinned to a specific commit, makepkg downloading the tarball from codeload automatically, then verifying integrity with sha256. Every source fetch has a fixed commit and checksum, and CI rejects anything that bypasses that pattern.
The codeload-commit pattern also brings "where the source comes from" into scope of verification: the commit and sha256 hardcoded in the PKGBUILD mean that even if the upstream repository is later modified or deleted, builds still use the exact source that was reviewed. Reproducibility is not a bonus; it is a precondition of review — a package that cannot be reproduced never enters this pipeline.
One more layer completes the picture for users who update often: the signed repository guarantees what you install is what the project published, and linxira-update pairs with it by creating a Timeshift snapshot before updates by default. Signature verification answers "is this authentic", snapshots answer "what if I do not like the result" — two different questions, and the update flow answers both without extra user action.
All of this lands on one everyday command: sudo pacman -Syu. Its safety precondition is — the repository you update is signed and trusted, every package you install is verified, and the package content passed the CI boundary check at the source. Remove any one of the three and an update can become an attack vector; with all three in place, updating is a trusted operation.
If you want to verify the system yourself, or build and reproduce these packages, see the building guide — it uses the same repository and signature mechanics as the release process. Supply-chain security is not a one-time configuration; it is a complete chain from PKGBUILD to pacman, auditable and reproducible at every link.
To close the loop back to the threat model: a replaced database is stopped by the database signature; a tampered package is stopped by the package signature; a package from an uncontrolled source is stopped by check-boundaries.sh before it is ever built. Each layer guards its own attack surface, and the user side needs no extra action for any of them — all three take effect automatically during install and update.