Debian Source-Only Uploads Explained

This article explores Debian's transition to mandatory source-only uploads, detailing what the practice entails and the security and technical motivations behind it. In Debian packaging, a source-only upload ensures that maintainers provide only raw source code rather than locally compiled binaries. By enforcing this requirement, the Debian project improved repository security, eliminated architecture biases, and laid the groundwork for verifiable, reproducible builds across its entire software archive.

What Is a Source-Only Upload?

In the Debian package distribution workflow, developers package upstream software alongside packaging metadata to generate source and binary packages. Historically, a maintainer would build the software locally and upload both the source package (the .dsc, the tarballs, and the .changes file) and the pre-compiled binary package (.deb files) for their native CPU architecture (typically amd64).

A source-only upload changes this workflow by completely stripping binary files from the maintainer's upload. The upload consists exclusively of source components and an associated .changes file that explicitly lists no .deb packages. Once accepted into the archive, the Debian infrastructure's automated build network—known as build daemons or "buildds"—takes the source code and builds the binaries for all supported architectures from scratch.

Why Debian Made Source-Only Uploads Mandatory

Debian established a policy requiring source-only uploads for packages migrating to the testing and stable branches to solve several critical issues associated with maintainer-built binaries:

1. Security and Archive Integrity

When maintainers uploaded pre-compiled binaries from their local workstations, Debian’s official distribution mirrors relied on the trust and security of individual developers' systems. If a maintainer's computer were infected with malware, a compromised binary could slip into the official repositories undetected, even if the uploaded source code appeared clean. Mandating source-only uploads ensures that all distributed binaries are generated exclusively by Debian’s centralized, auditable, and restricted buildd infrastructure.

2. Clean, Isolated Build Environments

Local developer environments often contain lingering development libraries, non-standard configurations, or packages from outside Debian's official archives. These local artifacts can inadvertently mask missing build dependencies or introduce unintended linkages in the resulting binary. Debian buildds compile software in clean, minimal, ephemeral environments (using tools like sbuild). A package will fail to build on the buildd if any dependency is omitted from the package metadata, ensuring dependencies are strictly documented and verified.

3. Parity Across Architectures

Previously, the architecture used by the maintainer enjoyed a special, unverified status because its binaries were built locally, whereas every other supported architecture (such as arm64, riscv64, or s390x) relied on buildds. Source-only uploads place every architecture on equal footing. Every binary distributed to end users is created using the exact same automated processes, regardless of hardware platform.

4. Supporting the Reproducible Builds Initiative

Debian is a primary driver of the Reproducible Builds project, which aims to ensure that given the exact same source code, build environment, and build instructions, any party can produce bit-for-bit identical binary packages. Enforcing source-only uploads allows Debian to log exact build paths, environment variables, and toolchain versions, making it possible for third parties to independently rebuild packages and verify that the distributed binaries have not been tampered with.