Binary_Build_Locations.mw

{{Header}}
{{title|title=
Who Controls the Download Factory?
}}
{{#seo:
|description=Explains who controls the computers that turn Open Source code into official downloads, and why outside build infrastructure can create build-time backdoor risk.
}}
{{malware_mininav}}
{{intro|
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:

{{quotation
|quote=Who controlled the computer that created the official downloads?
|context=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:

{{quotation
|quote=The recipe may be public, but the finished meal still depends on the kitchen.
|context=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.

{| class="wikitable"
|+ ''Plain-language comparison''
|-

! <!-- Column Headers --> Question
! <!-- Project controlled build --> Project-controlled or developer-controlled build
! <!-- Third-party hosted build --> Third-party-hosted build
|-

! <!-- question --> Who controls the build computer?
| <!-- project controlled build --> The project, its developers, or its own infrastructure.
| <!-- third-party hosted build --> Another company or outside service.
|-

! <!-- question --> Does the user need to trust an extra build provider?
| <!-- project controlled build --> Usually no.
| <!-- third-party hosted build --> Yes.
|-

! <!-- question --> Does this automatically prove the download is safe or unsafe?
| <!-- project controlled build --> No.
| <!-- third-party hosted build --> No.
|-

! <!-- question --> Why might privacy and security users care?
| <!-- project controlled build --> The official build path depends less on outside infrastructure.
| <!-- third-party hosted build --> An outside build provider becomes part of the trusted path for the official downloads.
|-

|}

== Why this matters ==
{{quotation
|quote=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.
|context=Paraphrased expectation of security and privacy enthusiasts.
}}

That expectation is not part of the formal [https://opensource.org/osd {{osd}}]. The Open Source Definition is about source code freedoms. It does not require self-hosted builds, avoidance of proprietary infrastructure or [[Binary_Build_Locations#Reproducible_builds|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|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:

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

This is a supply-chain risk.

= Who creates official downloads? =

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

{| class="wikitable"
|+ Who creates the files users install?
|-

! <!-- Column Headers --> Project
! <!-- Project controlled build --> Project-controlled or developer-controlled build?
! <!-- Official binary build provider --> Build provider or location
! <!-- Plain explanation --> Plain explanation
! <!-- Evidence status --> Evidence
|-

! <!-- project --> [[Firefox|Mozilla Firefox]]
| <!-- project controlled build --> {{no}}, Third-party-hosted build
| <!-- provider --> <u>G</u>oogle <u>C</u>ompute <u>E</u>ngine (GCP)
| <!-- explanation --> Trusted Firefox Linux build workers are configured to run on Google Cloud infrastructure.
| <!-- evidence --> Mozilla says shippable builds were moved from AWS to GCP. Mozilla issue tracker and Firefox CI configuration provide additional technical evidence.<ref>
{{quotation
|quote=moving shippable builds and Android emulator tests from AWS over to GCP
|context=[https://discourse.mozilla.org/t/engineering-effectiveness-newsletter-august-and-september-2022-edition/106802 Mozilla Discourse: Engineering Effectiveness Newsletter, August and September 2022]
}}

Mozilla issue tracker: [https://phabricator.services.mozilla.com/D157765 Bug 1547111 - Migrate shippable builds from AWS to GCP r=ahal!,jmaher!]
</ref>
|-

! <!-- project --> [https://github.com/fork-maintainers/iceraven-browser Iceraven Browser]
| <!-- project controlled build --> {{no}}, Third-party-hosted build
| <!-- provider --> GitHub Actions, Microsoft
| <!-- explanation --> Iceraven release automation uses GitHub Actions. GitHub is owned by Microsoft.
| <!-- evidence --> Iceraven repository release automation statement.<ref>
[https://en.wikipedia.org/wiki/GitHub GitHub] is owned by Microsoft. See also [https://en.wikipedia.org/wiki/GitHub#GitHub_Actions GitHub Actions].

{{quotation
|quote=Release automation

We have now setup release automation so that Github actions automatically trigger a release build and publish a release when we push a tag to the repository.
|context=https://github.com/fork-maintainers/iceraven-browser
}}
</ref>
|-

! <!-- project --> Flathub / Flatpak packages distributed through Flathub
| <!-- project controlled build --> {{no}}, Third-party-hosted build
| <!-- provider --> Amazon AWS
| <!-- explanation --> Flathub's build orchestrator uses RunsOn. RunsOn runs jobs on AWS.
| <!-- evidence --> Flathub Vorarbeiter blog and RunsOn documentation. <ref>
Flatpak's build orchestrator [https://github.com/flathub-infra/vorarbeiter Vorarbeiter] according to a [https://docs.flathub.org/blog/vorarbeiter-2026 Flathub Vorarbeiter 2026 blog post] uses [https://runs-on.com/ RunsOn], which runs on AWS (Amazon).
</ref> See also chapter [[Binary_Build_Locations#Flathub_/_Flatpak|Flathub / Flatpak]].
|-

! <!-- project --> Debian
| <!-- project controlled build --> {{BlueBackground}} Distributed build infrastructure
| <!-- provider --> Various individuals and organizations
| <!-- explanation --> Debian build machines are operated by various organizations and individual supporters.
| <!-- evidence --> Debian machine database.<ref>
{{quotation
|quote=...

* conova communications GmbH
* individual Debian supporters (hardware)
* MIT Computer Science & Artificial Intelligence Lab (hosting)
* Greek Research and Technology Network (GRNET) (hosting)
* ...
|context=https://db.debian.org/machines.cgi?sortby=purpose&sortorder=dsc
}}
</ref>
|-

! <!-- project --> {{project_name_short}}
| <!-- project controlled build --> {{BlueBackground}} Project-controlled controlled and Debian.
| <!-- provider --> Developer machines and Debian infrastructure.
| <!-- explanation --> Project's own images and packages are built on developer machines. Binary Debian packages are downloaded from <code>packages.debian.org</code>.
| <!-- evidence --> {{project_name_short}} Trust wiki page. <ref>
[[Trust#Software_Build_Process_Security|{{project_name_short}} Trust wiki page, chapter Software Build Process Security]]
</ref>
|-

! <!-- project --> Qubes
| <!-- project controlled build --> {{BlueBackground}} Unknown / needs documentation
| <!-- provider --> Unknown / needs documentation. Build process downloads binary packages from <code>packages.debian.org</code> and Fedora.
| <!-- explanation --> The build location needs further research.
| <!-- evidence --> Related user discussion exists. <ref>
related discussion: [https://forum.qubes-os.org/t/update-philosophy-flaw/29098/13 Qubes forums: update philosophy flaw]
</ref>
|-

|}

= Project notes =

== Flathub / Flatpak ==

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

{{IntroLike|
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 "[[Binary_Build_Locations#Reproducible_builds|reproducible build]]" means someone can repeat the build and get the same result.

<u>Security and transparency concerns:</u>

* <u>Amazon-backed build infrastructure:</u> Flathub uses a build system called [https://github.com/flathub-infra/vorarbeiter Vorarbeiter]. Flathub describes Vorarbeiter as sitting between GitHub and GitHub Actions. Flathub later stated that it fully switched to [https://runs-on.com/ RunsOn] for all builds. RunsOn provides GitHub Actions runners using AWS infrastructure. AWS means [https://aws.amazon.com/ Amazon Web Services], Amazon's cloud platform. Therefore, current public Flathub documentation shows that Flathub builds use GitHub Actions, RunsOn, and AWS-backed infrastructure.<ref>
{{quotation
|quote=The new service is a middleman between GitHub and GitHub Actions.
|context=[https://docs.flathub.org/blog/vorarbeiter-is-here Flathub: Vorarbeiter is here]
}}

{{quotation
|quote=Since then, we have fully switched to RunsOn for all builds.
|context=[https://docs.flathub.org/blog/vorarbeiter-2026 Flathub: What's new in Vorarbeiter]
}}

{{quotation
|quote=Thank you RunsOn team and AWS for making this possible!
|context=[https://docs.flathub.org/blog/vorarbeiter-2026 Flathub: What's new in Vorarbeiter]
}}
</ref>

* <u>Build-time threat model:</u> 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.
** <u>Trusted infrastructure path:</u> 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.
** <u>Build-time attack surface:</u> 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.
** <u>No allegation of actual tampering:</u> This does not mean that Amazon, GitHub, RunsOn, or Flathub have inserted a backdoor, reviewed apps, or intentionally changed packages.
* <u>Build-from-source transparency:</u> 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. <ref>
{{quotation
|quote=All source available submissions must be built entirely from source code.
|context=[https://docs.flathub.org/docs/for-app-authors/requirements Flathub: Requirements]
}}

{{quotation
|quote=Exceptions can be granted on a case-by-case basis.
|context=[https://docs.flathub.org/docs/for-app-authors/requirements Flathub: Requirements]
}}
</ref>
** <u>No clear per-app source/prebuilt-files indicator:</u> 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 <code>flathub.org</code> was closed as not planned. <ref>
[https://github.com/flathub/flathub/issues/5733 Indicate on flathub.org Whether a Flatpak is Built from Source or Binary During Build Process on Flathub #5733]
</ref>
* <u>Reproducible builds:</u> Flathub has [https://builds.flathub.org/reproducible reproducible build results], which is laudable. However, reproducible builds do not remove all trust questions.
** <u>Limited reproducibility scope:</u> Flathub describes its reproducibility testing as testing <code>x86_64</code> builds targeting the stable repository. <ref>
{{quotation
|quote=We have started testing binary reproducibility of x86_64 builds targetting the stable repository.
|context=[https://docs.flathub.org/blog/vorarbeiter-2026 Flathub: What's new in Vorarbeiter]
}}
</ref>
** <u>Direct uploads and failures:</u> Flathub states that direct uploads are not currently tested by its reproducibility system and that reproducibility failures are not currently acted on. <ref>
{{quotation
|quote=Failures are not currently acted on. When we collect more results, we may start to surface them to app maintainers for investigation. We also don't test direct uploads at the moment.
|context=[https://docs.flathub.org/blog/vorarbeiter-2026 Flathub: What's new in Vorarbeiter]
}}
</ref>
** <u>Source versus packaging distinction:</u> 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.
** <u>Reporting-path trust:</u> The reproducibility checker says it rebuilds Flatpak apps published on Flathub and compares the result using <code>diffoscope</code>. <code>diffoscope</code> 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 <code>diffoscope</code> results. S3 means [https://aws.amazon.com/s3/ 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. <ref>
{{quotation
|quote=A tool to rebuild Flatpak apps published on Flathub and compare reproducibility using diffoscope.
|context=[https://github.com/flathub-infra/flathub-repro-checker flathub-repro-checker]
}}

{{quotation
|quote=boto3 is optionally used to upload diffoscope results as a zip file to Amazon S3
|context=[https://github.com/flathub-infra/flathub-repro-checker flathub-repro-checker]
}}
</ref>
*** <u>Reporting-path attack surface:</u> A compromised or malicious reporting/storage path could theoretically hide, replace, remove, or misrepresent reproducibility artifacts shown to users.
*** <u>Meaning of this limitation:</u> 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.
** <u>Hosted result trust:</u> 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.
** <u>Independent verification:</u> 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 [https://github.com/flathub-infra/flathub-repro-checker flathub-repro-checker], and at least one independent third-party tool exists: [https://github.com/zaclegarssure/flathub-rebuilder 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 <code>diffoscope</code>.
*** <u>No independent public rebuilder dashboard found:</u> No widely used independent public rebuilder dashboard for Flathub was found.
*** <u>Flathub-hosted public results:</u> The public reproducibility results at [https://builds.flathub.org/reproducible builds.flathub.org/reproducible] are Flathub-hosted.

Related:

* [[Install_Software#Flathub_Package_Sources_Security|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 [[Trust#Builds_from_Source_Code_versus_Builds_including_Binary_Packages|Builds from Source Code versus Builds including Binary (pre-built) Packages]] and [[Dev/bootstrappable_builds|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:

{{quotation
|quote=Can someone else independently produce the same program from the same source code?
|context=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:

{{quotation
|quote=If the original meal was cooked in Amazon's kitchen, the strongest check is not another check controlled by the same kitchen.
|context=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:

* <u>Original build:</u> The official program was built using third-party infrastructure.
* <u>Rebuild check:</u> 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:

* <u>Independent rebuilders:</u> Other people or organizations can rebuild the software on separate infrastructure, and the project makes this practical and encouraged.
* <u>Independent reporting:</u> Reproducibility results can be checked without relying only on the original project's website or the same cloud provider.
* <u>Public comparison:</u> Differences between binaries can be inspected with tools such as <code>diffoscope</code>.
* <u>Multiple parties:</u> 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 ==

[[Dev/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 =

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

= What this page does not claim =

* <u>No compromise claim:</u> This page does not claim that every third-party build is compromised.
* <u>No automatic safety claim:</u> This page does not claim that project-controlled builds are automatically safe.
* <u>No automatic insecurity claim:</u> This page does not claim that third-party-hosted builds are automatically unsafe.
* <u>No source-code dismissal:</u> This page does not claim that source code availability is useless.
* <u>No malware accusation:</u> This page does not claim that the listed projects are malicious.
* <u>No complete supply-chain audit:</u> 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:

<div class="use-3-columns strict-list-columns mw-collapsible-content">
* [[About|{{project_name_short}}]]:
** [[Miscellaneous_Threats_to_User_Freedom|General Threats to User Freedom]]
** [[Windows_Hosts|Microsoft Windows Hosts]]
<div></div>
* [https://consumerrights.wiki/w/Main_Page Consumer Rights Wiki]:
** [https://consumerrights.wiki/w/Google Google]
** [https://consumerrights.wiki/w/Microsoft Microsoft] / [https://consumerrights.wiki/w/Microsoft_Windows Windows]
** [https://consumerrights.wiki/w/Amazon Amazon]
</div>

= 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 [https://sfconservancy.org/GiveUpGitHub/ 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. <ref>
{{quotation
|quote=GitHub itself is the very opposite of FOSS.
|context=[https://sfconservancy.org/GiveUpGitHub/ Software Freedom Conservancy: Give Up GitHub]
}}

{{quotation
|quote=reject GitHub's proprietary services
|context=[https://sfconservancy.org/GiveUpGitHub/ Software Freedom Conservancy: Give Up GitHub]
}}
</ref>

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. <ref>
{{quotation
|quote=Het hosten van broncode is een kritiek onderdeel van de infrastructuur
|context=[https://developer.overheid.nl/blog/2025/11/11/git-forge-overheid Developer Overheid: Aanbeveling voor de Git-werkplaats van de overheid]
}}

{{quotation
|quote=volledige beschikking te hebben over een Git-forge
|context=[https://developer.overheid.nl/blog/2025/11/11/git-forge-overheid Developer Overheid: Aanbeveling voor de Git-werkplaats van de overheid]
}}
</ref>

A later Dutch government page says <code>code.overheid.nl</code> is fully self-hosted and supports digital sovereignty. <ref>
{{quotation
|quote=fully self-hosted and supports digital sovereignty
|context=[https://www.nldigitalgovernment.nl/news/soft-launch-for-government-open-source-code-platform/ Digital Government: Soft launch of open-source code platform for government]
}}
</ref>

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. <ref>
{{quotation
|quote=malware that attacks the software development and build processes
|context=[https://blog.torproject.org/deterministic-builds-part-one-cyberwar-and-global-compromise/ Tor Project: Deterministic Builds Part One]
}}
</ref>

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. <ref>
{{quotation
|quote=independently-verifiable path from source to binary code
|context=[https://reproducible-builds.org/ Reproducible Builds]
}}

{{quotation
|quote=detect unauthorized changes to the build process early
|context=[https://reproducible-builds.org/ Reproducible Builds]
}}
</ref>

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. <ref>
{{quotation
|quote=introduce behavior to an artifact without changing its source code
|context=[https://slsa.dev/spec/v1.2/threats SLSA: Threats and mitigations]
}}
</ref>

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. <ref>
{{quotation
|quote=Details specific to this particular execution of the build.
|context=[https://slsa.dev/spec/v1.0/provenance SLSA: Provenance]
}}
</ref>

== 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. <ref>
{{quotation
|quote=leaving the source code unmodified
|context=[https://go.dev/blog/rebuild Go Blog: Perfectly Reproducible, Verified Go Toolchains]
}}

{{quotation
|quote=posted binaries are free of hidden changes
|context=[https://go.dev/blog/rebuild Go Blog: Perfectly Reproducible, Verified Go Toolchains]
}}
</ref>

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. <ref>
{{quotation
|quote=verified by multiple builders
|context=[https://gitian.org/ Gitian]
}}

{{quotation
|quote=single point of failure
|context=[https://gitian.org/ Gitian]
}}
</ref>

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. <ref>
{{quotation
|quote=no one person or computer needs to be trusted
|context=[https://bitcoinops.org/en/topics/reproducible-builds/ Bitcoin Optech: Reproducible builds]
}}
</ref>

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. <ref>
{{quotation
|quote=preventing attacks targeting the complex systems
|context=[https://www.opentech.fund/security-safety-audits/reproducible-builds-security-audit/ Open Technology Fund: Reproducible Builds]
}}
</ref>

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.

* [https://www.reddit.com/r/firefox/comments/cplazy/why_does_firefox_send_use_googles_servers/ Reddit: Why does Firefox Send use Google's servers?]
* [https://www.reddit.com/r/privacy/comments/11r6cnl/firefox_extends_its_antitracking_protection_to/ Reddit: Firefox background connections including *.mozgcp.net]
* [https://www.reddit.com/r/firefox/comments/1qggioc/how_to_prevent_firefox_144_from_automatically/ Reddit: How to prevent Firefox from automatically connecting to servers on startup]
* [https://www.reddit.com/r/pihole/comments/1aqn2or/mozgcpnet/ Reddit: mozgcp.net blocked by Pi-hole]
* [https://askubuntu.com/questions/1353670/firefox-repeated-connections-to-googleusercontent-com-just-in-firefox Ask Ubuntu: Firefox repeated connections to googleusercontent.com]
* [https://forum.linuxguides.de/index.php?thread/10984-firefox-verbindungen-zu-bc-googleusercontent-com/ LinuxGuides: Firefox Verbindungen zu bc.googleusercontent.com]
* [https://www.linuxquestions.org/questions/general-10/what%27s-going-on-with-googleusercontent-com-4175729819/ LinuxQuestions: What's going on with googleusercontent.com?]
* [https://forums.freebsd.org/threads/googlecontent.92184/ FreeBSD Forums: googlecontent]
* [https://forums.linuxmint.com/viewtopic.php?t=456230 Linux Mint Forums: Firefox strange behavior]

== Polls ==

* [https://x.com/Whonix/status/2050978669883949115 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 =
<references />
[[Category:Documentation]]
{{Footer}}