Trust Models: Decentralized vs Distributed vs Centralized

Introduction

The security of a Linux distribution depends on where trust is placed and how it is enforced. Every distribution must answer the same fundamental questions: who can modify source code, who can sign packages, who controls the build infrastructure, and what minimum level of agreement is required before artifacts are considered trustworthy.

The answers to these questions define a distribution's trust model. Trust models exist on a spectrum. At one end, centralized models place authority in a single entity or small group. At the other end, decentralized models distribute authority across multiple independent actors and require a quorum of them to agree before any action is binding. Between these extremes lies the distributed model, where multiple actors have authority but no minimum quorum is enforced -- any single actor can act unilaterally.

This distinction is not merely theoretical. The xz backdoor incident of 2024 demonstrated that a single trusted maintainer, operating within a distributed trust model, can introduce malicious code into a critical system library. The attacker exploited the fact that no quorum was required: one person's approval was sufficient. Understanding these trust models is essential for evaluating the real-world security posture of any distribution, including StageX.

Centralized Trust (Single Point of Failure)

In a centralized trust model, a single entity, small team, or automated system controls the authority to sign packages and approve changes. The distribution's security rests on the integrity of that central point. If it is compromised, the entire distribution is compromised.

Alpine Linux uses per-maintainer RSA key pairs for package signing. Each package carries a DER-encoded PKCS#1 v1.5 RSA signature, and the APKINDEX repository index is similarly signed. While this per-maintainer model distributes signing authority in name, any single maintainer can sign and publish packages independently. There is no quorum requirement and no independent reproduction step before publication.

Fedora centralizes all official builds through the Koji build system. Packages are signed with a single per-release GPG key. The signing key itself is hosted on centralized infrastructure. While Fedora has a peer-review process for package changes, the final build and signing step is a single point of control.

Debian employs a centralized archive signing model. Release files are signed by automatic archive keys managed by the ftp-master team. These Release files chain to Packages files containing hashes of individual binary packages. While Debian developers sign uploads with individual OpenPGP keys, the final archive-level signature is singular. As Debian's own documentation acknowledges, "if the archive is compromised then every package is compromised."

Centralized models concentrate both capability and risk. Compromise of a single signing key or build server is sufficient to deliver malicious artifacts to every user. The xz backdoor exploited similar single-point dynamics: one maintainer, Jia Tan, was able to push malicious code because single-maintainer trust was sufficient at every level of the approval chain.

Distributed Trust (Multiple Independent Actors, No Quorum)

In a distributed trust model, multiple individuals have the authority to sign and publish, but no minimum number of signers is required. Any single authorized actor can act independently.

Arch Linux uses a web-of-trust approach. A set of Master Signing Keys signs individual developer keys, which in turn sign packages. While this creates a two-level hierarchy, each maintainer remains a single point of failure for their packages. Compromise of a developer key allows arbitrary modifications to appear legitimate.

Debian (as distinct from its archive signing) uses individual developer keys for uploads. Any Debian Developer whose key is in the keyring can upload packages. The project has moved toward source-only uploads but still permits individual maintainer authority.

GNU Guix requires that commits to its core repository be signed by OpenPGP keys belonging to recognized developers. Keys are tracked within the repository, and Guix verifies that updates are signed by an authorized key and descend from a previously authenticated commit. However, any single authorized committer can merge changes. Guix also relies on centralized substitute servers as the default binary cache for most users.

In each of these cases, the model is distributed in the sense that authority is spread across many people, but it is not decentralized: no minimum quorum is required, so a single compromised key or account can be exploited. The distributed model is an improvement over centralized trust in that compromise requires targeting a specific individual rather than a single high-value server, but the blast radius of a successful compromise remains total for the affected packages.

Decentralized Trust (Quorum-based)

Decentralized trust requires agreement from multiple independent parties before any action takes effect. No single individual, key, or system has unilateral authority. Compromise requires subverting multiple actors simultaneously.

StageX implements decentralized trust across two dimensions:

Source code changes. Every change to the StageX source tree must be reviewed and signed off by at least two maintainers. Pull requests flow through a strict pipeline: PR branch -> staging -> release branch -> staging -> main. Each merge requires a signed merge commit. A single maintainer merging code -- even with a signed commit -- is explicitly insufficient per the project's maintainer guidelines. This policy eliminates the single-maintainer vulnerability that enabled the xz backdoor.

Build artifact signing. Every published artifact must be independently reproduced by at least two maintainers using diverse hardware before signing. Maintainers build on different machines (AMD and Intel CPUs, different locations, different operating systems), compute SHA-256 digests of the output, and compare results. Only when the digests match do both maintainers sign. The build system enforces this programmatically: the publish-* Makefile targets count signatures and refuse to proceed with fewer than two.

StageX's Quorum Design in Practice

The quorum requirement is enforced at multiple levels:

Maintainers. StageX currently has eight maintainers distributed across North America and Europe, operating diverse hardware (AMD Threadripper, EPYC, Ryzen; Intel Core; QubesOS, Debian, Arch Linux, Fedora). Each uses hardware smart cards (YubiKey 5, NitroKey 3) with PIN protection and touch-required signing. Private key material is never exposed to internet-connected environments.

Signature enforcement. The publish-{stage}-{name} target in the build system (generated by src/targets.py) executes:

signum="$$(ls -1 signatures/stagex/{stage}-{name}@sha256=$${{digest}} | wc -l)";
[ $${{signum}} -ge 2 ] || { echo "Error: Minimum signatures not met"; exit 1; };

This is not a convention or a social norm. It is a hard gate in the automated build pipeline. A release cannot proceed without meeting the quorum.

Independent reproduction. The MAINTENANCE.md policy requires that the full tree be reproduced on at least two different CPU vendors (e.g., AMD and Intel) to detect vendor-specific microarchitectural backdoors. The MAINTAINERS file records machine specifications for traceability.

Signature storage. Signatures are stored in a separate repository (sigs.stagex.tools), independent of both the source repository and the image registry. This lookaside architecture means that compromising a registry does not grant the ability to forge or tamper with signatures.

Comparison Table

Why Decentralized Is Superior

Decentralized trust eliminates the fundamental vulnerability that the whitepaper identifies as the common thread across all mainstream Linux distributions: the ability of a single actor to unilaterally compromise distribution integrity.

In a centralized model, the attacker targets one key or one server. In a distributed model, the attacker targets one maintainer. In a decentralized model, the attacker must simultaneously subvert multiple independent actors with different hardware, different operating systems, different physical locations, different security postures, and different operational practices. The attack surface is not a single point but a diverse, distributed set of constraints.

This does not mean decentralized trust is without tradeoffs. Multi-party signing introduces contributor friction: every change requires coordination and review by multiple people. Reproducing every build on diverse hardware increases the time between commit and release. These tradeoffs are acceptable for high-assurance environments where the cost of a single point of failure far exceeds the cost of operational overhead.

For threat models that assume a capable, persistent adversary -- including nation-state actors -- decentralized trust is not an improvement over other models. It is the minimum viable architecture.

See Also

• Multi-Sig: Decentralized Quorum Signing -- Technical details of the signing protocol and key management
• Comparison: StageX vs Other Distributions -- Distribution comparison across all five core criteria
• Reference: Glossary -- Definitions of trust model terminology
• Tutorial: Verifying Your First StageX Image -- Practical verification of multi-sig attestations
• How-To: Verify Multi-Signature Attestations -- Step-by-step verification instructions