Who Controls the Download Factory?

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

• Malware, Computer Viruses and Antivirus Scanners
• Backdoor
• About Computer Security
• Binary Build Locations
• Deep Scan Ready

Many Open Source users expect official downloads to be built by the project's own developers or infrastructure. For example, many users may expect official Firefox downloads to be built by Mozilla-controlled infrastructure. If official downloads are instead built on infrastructure controlled by companies such as Google, Microsoft, Amazon, GitHub, or similar providers, those providers become part of the trusted build path. This can create build-time backdoor risk.

Simple explanation

This section is for non-technical readers. More technical details follow later.

Many users choose Open Source software because the source code can be inspected, shared, modified, and rebuilt.

However, most users do not build software themselves. They download the official program.

The important question is:

Who controlled the computer that created the official downloads?Plain-language build trust question.

Recipe analogy

Imagine Open Source software as a recipe.

• The source code is the recipe that people can read.
• The official downloads is the finished meal that users actually receive.
• The build computer is the kitchen that turns the recipe into the finished meal.

In software, this process is called a build.

The concern is simple:

The recipe may be public, but the finished meal still depends on the kitchen.Build trust analogy.

If someone else controls the kitchen, users must trust both the recipe author and that kitchen.

Two build models

Project-controlled or developer-controlled build

The Open Source project, its developers, or its own infrastructure control the computers that create the official downloads.

Users still need to trust the project. This does not automatically make the download secure. It only means the project has not handed the build computers themselves to an outside build service.

Third-party-hosted build

The project publishes the source code, but another organization controls the computers that create the official downloads.

Examples include GitHub Actions, Google Cloud, Microsoft Azure, Amazon AWS, or another hosted CI/build provider.

Plain-language comparison

Question	Project-controlled or developer-controlled build	Third-party-hosted build
Who controls the build computer?	The project, its developers, or its own infrastructure.	Another company or outside service.
Does the user need to trust an extra build provider?	Usually no.	Yes.
Does this automatically prove the download is safe or unsafe?	No.	No.
Why might privacy and security users care?	The official build path depends less on outside infrastructure.	An outside build provider becomes part of the trusted path for the official downloads.

Why this matters

If I choose Open Source to avoid Google, Microsoft, Amazon, or similar companies, the official downloads should not silently depend on those same companies as trusted build authorities.Paraphrased expectation of security and privacy enthusiasts.

That expectation is not part of the formal The Open Source Definition (OSD). The Open Source Definition is about source code freedoms. It does not require self-hosted builds, avoidance of proprietary infrastructure or reproducible builds.

Therefore, a project can be Open Source while still using third-party build infrastructure.

Build-time backdoor risk in plain language

A build-time backdoor is a malicious change introduced while source code is being turned into an official download.

This is different from a source-code backdoor.

With a source-code backdoor, the malicious code is visible in the public source code.

With a build-time backdoor, the public source code may look clean, but the finished program could theoretically be changed during the build.

A malicious or compromised build environment could theoretically:

• Inject a backdoor: Add malicious code during the build process that is not visible in the public source code.
• Modify the application: Produce an official download that differs from what independent users would expect from the source code.
• Steal signing secrets: Abuse build credentials, release tokens, or signing keys if these are available to the build system.
• Target only some users: Serve or produce different binaries for specific users, regions, platforms, or release channels.
• Hide the change: Leave the source code unchanged while modifying only the build output or release artifact.

This is a supply-chain risk.

Who creates official downloads?

Comparison of who controls the computer that create official downloads for selected Open Source software projects.

Who creates the files users install?

Project	Project-controlled or developer-controlled build?	Build provider or location	Plain explanation	Evidence
Mozilla Firefox	No, Third-party-hosted build	Google Compute Engine (GCP)	Trusted Firefox Linux build workers are configured to run on Google Cloud infrastructure.	Mozilla says shippable builds were moved from AWS to GCP. Mozilla issue tracker and Firefox CI configuration provide additional technical evidence.
Iceraven Browser	No, Third-party-hosted build	GitHub Actions, Microsoft	Iceraven release automation uses GitHub Actions. GitHub is owned by Microsoft.	Iceraven repository release automation statement.
Flathub / Flatpak packages distributed through Flathub	No, Third-party-hosted build	Amazon AWS	Flathub's build orchestrator uses RunsOn. RunsOn runs jobs on AWS.	Flathub Vorarbeiter blog and RunsOn documentation. See also chapter Flathub / Flatpak.
Kicksecure	Yes, Project-controlled or developer-controlled build	Developer machines	Images and packages are built on developer machines.	Kicksecure Trust wiki page.
Qubes	Unknown / needs documentation	Unknown / needs documentation	The build location needs further research.	Related user discussion exists.
Debian	Distributed build infrastructure	Various individuals and organizations	Debian build machines are operated by various organizations and individual supporters.	Debian machine database.

Project notes

Flathub / Flatpak

Time of writing of this Flathub / Flatpak chapter: May 2026

Flathub's current public documentation says its build system uses GitHub Actions together with RunsOn, which provisions build machines on AWS, Amazon's cloud platform.

In simple terms, a "build" means turning source code and other declared inputs into the final Flatpak package that users install. A "reproducible build" means someone can repeat the build and get the same result.

Security and transparency concerns:

• Amazon-backed build infrastructure: Flathub uses a build system called Vorarbeiter. Flathub describes Vorarbeiter as sitting between GitHub and GitHub Actions. Flathub later stated that it fully switched to RunsOn for all builds. RunsOn provides GitHub Actions runners using AWS infrastructure. AWS means Amazon Web Services, Amazon's cloud platform. Therefore, current public Flathub documentation shows that Flathub builds use GitHub Actions, RunsOn, and AWS-backed infrastructure.

• Build-time threat model: Because the documented build path uses GitHub Actions, RunsOn, and AWS-backed infrastructure, those systems should be treated as part of the trusted build path.
  • Trusted infrastructure path: It means that AWS-backed infrastructure is part of Flathub's documented build path, and that Amazon S3 may also be used for storing build-comparison reports.
  • Build-time attack surface: In the general threat model of this page, a compromised build runner, malicious insider, or legally compelled infrastructure provider could theoretically affect the finished Flatpak even if the public source code looked clean. This is the build-time backdoor concern described earlier on this page.
  • No allegation of actual tampering: This does not mean that Amazon, GitHub, RunsOn, or Flathub have inserted a backdoor, reviewed apps, or intentionally changed packages.
• Build-from-source transparency: Flathub has a policy saying that source-available submissions should be built entirely from source code, including runtime dependencies included in the manifest, with possible exceptions.
  • No clear per-app source/prebuilt-files indicator: Flathub does not currently prominently show ordinary users whether a specific Flatpak was fully built from source code or whether any already-built upstream files were used during the build process. A feature request to show this on flathub.org was closed as not planned.
• Reproducible builds: Flathub has reproducible build results, which is laudable. However, reproducible builds do not remove all trust questions.
  • Limited reproducibility scope: Flathub describes its reproducibility testing as testing x86_64 builds targeting the stable repository.
  • Direct uploads and failures: Flathub states that direct uploads are not currently tested by its reproducibility system and that reproducibility failures are not currently acted on.
  • Source versus packaging distinction: Reproducible packaging is not the same as proving that everything was compiled from original source code. It proves that the same recipe produced the same Flatpak again. If the recipe used a prebuilt upstream program as an input, reproducibility shows that the same program was packaged again in the same way.
  • Reporting-path trust: The reproducibility checker says it rebuilds Flatpak apps published on Flathub and compares the result using diffoscope. diffoscope is a tool that compares two build outputs and explains what differs. The checker documentation also says Amazon S3 upload support is optional and used for uploading diffoscope results. S3 means Amazon S3, Amazon's cloud object storage service. S3 is storage, not a build machine. This means Amazon infrastructure may be used to store or serve detailed comparison reports.
    • Reporting-path attack surface: A compromised or malicious reporting/storage path could theoretically hide, replace, remove, or misrepresent reproducibility artifacts shown to users.
    • Meaning of this limitation: This does not by itself prove that Amazon determines or manipulates the result; it means the hosted reporting path is another part of the trust model.
  • Hosted result trust: If users only read Flathub's own reproducibility page or Flathub-linked reports, they are trusting Flathub's reporting setup. This is not the same as an independent third-party rebuild. A malicious build path could theoretically affect the produced Flatpak, while a malicious or compromised reporting path could theoretically affect the reproducibility status or comparison artifacts that users see afterward.
  • Independent verification: Independent rebuilders matter because they let people check Flathub's claims without relying only on Flathub's own website. Volunteers can run Flathub's own flathub-repro-checker, and at least one independent third-party tool exists: flathub-rebuilder. It is described as a command line tool to verify a Flatpak locally, recreate a Flatpak from Flathub by name, and compare results using diffoscope.
    • No independent public rebuilder dashboard found: No widely used independent public rebuilder dashboard for Flathub was found.
    • Flathub-hosted public results: The public reproducibility results at builds.flathub.org/reproducible are Flathub-hosted.

Related:

• Flathub Package Sources Security

Forum discussion:

• https://discourse.flathub.org/t/flathub-infrastructure-security/1618

Open Source Operating Systems

What "building from source code" means in the context of building Open Source operating systems from source code is not well defined. See also Builds from Source Code versus Builds including Binary (pre-built) Packages and bootstrappable builds.

Related but different topics

Binary means pre-built applications.

This page is related to reproducible builds, binary transparency, and bootstrappable builds, but it is not the same topic.

Reproducible builds

Reproducible builds answer the question:

Can someone else independently produce the same program from the same source code?Reproducible builds question.

That is related, but separate.

A project may use a third-party build provider and still work toward reproducible builds.

A project may also build on its own machines but still fail to provide reproducible builds.

Reproducible builds are strongest when the rebuild is independent from the original build infrastructure.

In simple terms:

If the original meal was cooked in Amazon's kitchen, the strongest check is not another check controlled by the same kitchen.Reproducible builds and independent verification analogy.

For strongest verification, reproducible build checks should be possible outside the same cloud company or hosted build platform used for the official build.

Otherwise, users may still need to trust the same provider in two places:

• Original build: The official program was built using third-party infrastructure.
• Rebuild check: The reproducibility result or comparison report was also produced, stored, or served using third-party infrastructure.

This does not make reproducible builds useless.

Reproducible builds are still valuable because they make hidden changes harder.

But if the official build, the rebuild, and the reproducibility report all depend on large cloud providers or hosted platforms, then the verification is less independent than it appears.

The strongest model is:

• Independent rebuilders: Other people or organizations can rebuild the software on separate infrastructure, and the project makes this practical and encouraged.
• Independent reporting: Reproducibility results can be checked without relying only on the original project's website or the same cloud provider.
• Public comparison: Differences between binaries can be inspected with tools such as diffoscope.
• Multiple parties: More than one independent party can confirm the same result.

This page therefore treats reproducible builds as helpful, but not a complete answer to the build location question.

Binary transparency

Binary transparency is about making published binaries (programs) visible and auditable over time.

This page is about who controls the infrastructure that creates the binary in the first place.

Bootstrappable builds

Bootstrappable builds ask how much pre-existing binary software is needed to build the system from source code.

This page asks where the official binaries are built and who controls that infrastructure.

Technical terminology

The technical version is:

Outsourced build trust is the security and privacy gap created when an Open Source project's official binaries are built, signed, stored, or published using infrastructure controlled by a third party, such as a proprietary CI provider or hyperscaler.

This makes the third party part of the trusted computing base, even when the source code itself is open.

Open Source users often assume that "open source" reduces dependency on proprietary vendors and opaque infrastructure. However, official binaries may be produced on hosted CI/CD systems or cloud infrastructure controlled by Microsoft, Google, Amazon, or other third parties. In that case, the source code may be open, but the binary build path still depends on a proprietary build trust boundary.

This is not solved merely by source availability. It requires transparent build provenance, independent rebuilds, reproducible or verifiable builds, controlled signing key custody, and disclosure of build infrastructure.

Security and privacy enthusiasts typically expect sovereign build infrastructure.

Many developers optimize for convenience, cost, and automation. Hyperscalers made it easy and fast to build releases, create digital software signatures, and publish software. For small and medium projects, running independent build infrastructure may be expensive and operationally difficult.

What this page documents

• Build locations: Where official software binaries are built, where that information is publicly known.
• Build infrastructure: Whether official binaries are built on developer machines, self-hosted infrastructure, Google Cloud, Microsoft Azure, Amazon AWS, GitHub Actions, or other third-party infrastructure.
• Trust relationships: The trust relationship created when the official program is built, signed, stored, or published through infrastructure controlled by someone other than the project itself.
• Project comparisons: Multiple Open Source projects are compared. Kicksecure is included as one example, but the topic is general.

What this page does not claim

• No compromise claim: This page does not claim that every third-party build is compromised.
• No automatic safety claim: This page does not claim that project-controlled builds are automatically safe.
• No automatic insecurity claim: This page does not claim that third-party-hosted builds are automatically unsafe.
• No source-code dismissal: This page does not claim that source code availability is useless.
• No malware accusation: This page does not claim that the listed projects are malicious.
• No complete supply-chain audit: This page does not attempt to fully audit every build system, signing key, dependency, maintainer, mirror, or hosting provider.

Related background

This page does not attempt to explain every criticism of Google, Microsoft, Amazon, or similar companies. The narrower point of this page is build infrastructure.

For broader background, see:

• Kicksecure:
  • General Threats to User Freedom
  • Microsoft Windows Hosts

• Consumer Rights Wiki:
  • Google
  • Microsoft / Windows
  • Amazon

Related arguments from other projects and organizations

This concern is not unique to this page.

Other Free Software, Open Source, government, and software supply-chain security sources also treat build infrastructure, developer infrastructure, reproducible builds, and binary provenance as part of the software trust path.

Proprietary developer infrastructure

The Software Freedom Conservancy argues that Free and Open Source Software projects should not normalize reliance on GitHub's proprietary developer infrastructure. This supports the broader point that the tools and platforms used to develop and publish Open Source software can matter, not only the source license.

This does not by itself prove that GitHub-built binaries are malicious. It supports the narrower claim that proprietary developer infrastructure can be controversial for FOSS projects.

Sovereign source and binary infrastructure

The Dutch government developer portal makes a direct integrity argument about code and binaries. It argues that hosting source code is critical infrastructure, that code or binaries in repositories must not be tampered with, and that the government needs full control over its Git forge.

A later Dutch government page says code.overheid.nl is fully self-hosted and supports digital sovereignty.

This is close to the concern discussed on this page: whoever controls the infrastructure can become part of the trust path for source code, binaries, and releases.

Build-system compromise and signed malware

The Tor Project's deterministic builds article gives a strong build-time attack model. It argues that malware can attack software development and build processes themselves, and that deterministic, distributed builds are a defense against targeted attacks.

In simpler terms: the danger is not only malicious source code. The danger can also be malicious infrastructure that turns clean source code into a malicious official binary.

Reproducible builds and independent verification

The Reproducible Builds project describes reproducible builds as creating an independently verifiable path from source code to binary code. It also says reproducible builds help detect unauthorized changes to the build process and give users confidence that downloaded binaries match the untampered source code.

This supports the point that source code visibility alone is not enough. Users also need ways to verify that the binary corresponds to the intended source and build process.

Build provenance and supply-chain threat models

SLSA describes a build integrity threat as an adversary introducing behavior into an artifact without changing the source code. This directly matches the build-time backdoor concern discussed on this page.

SLSA provenance also records details about the build, including the builder identity, build parameters, dependencies, and execution details. This supports documenting who built the binary, how it was built, and what infrastructure was involved.

Binaries can differ from source code

The Go project explains the source-to-binary problem in plain terms: Open Source code can be inspected, but most users download compiled binaries, and a supply-chain attacker could replace served binaries while leaving the source code unchanged.

The Go article also gives a useful independence lesson: verifying a package without using the same software stack can be a stronger check than rebuilding inside the same environment that may have been compromised.

Multiple independent builders

Gitian describes a software distribution method where binaries are verified by multiple builders. It says this removes the build and distribution process as a single point of failure.

Bitcoin Optech similarly explains that reproducible builds mean no single person or computer needs to be trusted to produce the executable binaries most users run.

This supports the positive model discussed on this page: independent rebuilders are stronger than relying on one build computer, one company, or one hosted platform.

Civil-society security framing

The Open Technology Fund describes reproducible builds as creating an independently verifiable path from source to binary and preventing attacks against the complex systems that build shared digital infrastructure.

This supports treating build systems as security-sensitive infrastructure, especially for privacy, security, and Internet freedom software.

User discussion

These discussions show that some users notice and question connections to Google, cloud infrastructure, or opaque binary build and hosting paths.

Some of these discussions are about network connections or hosting, not build machines. They are included to show that some users do notice and question third-party infrastructure behind Open Source software.

• Reddit: Why does Firefox Send use Google's servers?
• Reddit: Firefox background connections including *.mozgcp.net
• Reddit: How to prevent Firefox from automatically connecting to servers on startup
• Reddit: mozgcp.net blocked by Pi-hole
• Ask Ubuntu: Firefox repeated connections to googleusercontent.com
• LinuxGuides: Firefox Verbindungen zu bc.googleusercontent.com
• LinuxQuestions: What's going on with googleusercontent.com?
• FreeBSD Forums: googlecontent
• Linux Mint Forums: Firefox strange behavior

Polls

• When you download an official Open Source app, who do you think built the installable file?

todo

petition

flatpak bug report

document Amazon threat model or stop using Amazon

flatpak reddit

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!