Was Your Open-Source App Built From Its Source?

Publishing source code and shipping an app are two separate acts. The source on GitHub does not prove the file on your phone came from it. Only an independent rebuild that produces the same bytes — a reproducible build — links the two, and for some apps you can check, in minutes, whether anyone has done it.

On 29 March 2024, Andres Freund told the oss-security mailing list what he had found after noticing SSH logins using too much CPU on Debian's unstable branch: "The upstream xz repository and the xz tarballs have been backdoored." Then the detail that matters here: "One portion of the backdoor is solely in the distributed tarballs."¹ The file people downloaded contained code the public repository did not.

The official record, CVE-2024-3094, carries a CVSS 3.1 base score of 10.0 — the maximum — and says malicious code was discovered "in the upstream tarballs of xz, starting with version 5.6.0."² Chris Lamb and Stefano Zacchiroli had put the general point in one sentence three years earlier: "trusting code is not the same as trusting its executable counterparts."³

So the question for anyone who chose an app partly because it is open source is simple to state. Was your open-source app built from its source — and has anyone checked?

Everything below is as observed on 25 September 2026. You will not build anything. The check is reading what others have already published — and knowing what it cannot tell you.

The single habit: look for a rebuild, not a promise

The habit is to ask one question of any app you trust with your notes: has anyone other than the developer rebuilt this exact version from its public source and got the same file? A licence, a GitHub link and an "open source" badge answer a different question — whether you could read the code.

The Reproducible Builds project defines the property precisely: "A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts."⁴ The same page is strict about what "identical" means: "The reproducibility of artifacts is verified by bit-by-bit comparison."⁴ Close is not the test. The same bytes are.

The value is in who does the rebuilding. Identical results, in the project's words, allow "multiple third parties to come to a consensus" on the correct output, "highlighting any deviations as suspect and worthy of scrutiny."⁵ You do not have to be one of those parties. You only have to find out whether they exist.

This is not a fringe practice. Lamb and Zacchiroli reported in IEEE Software that "over 95% of the 30 000+ packages in Debian's development branch can now be built reproducibly."³ Debian's live dashboard showed 94.3% of 41,327 source packages in its unstable branch on amd64 as of 25 September 2026.⁶ The archive grew; the share held.

Nobody expects you to rebuild anything yourself — only to look for someone who did.

What the xz backdoor shows — and what it does not

The xz backdoor shows both halves of this check. The release file contained code the public repository did not, so the source is public was not enough. But most of the malicious code was in the repository, so a rebuild that faithfully matched the release would have reproduced the backdoor.

The first half is the gap. The piece that switched the attack on — a line in a build script — sat only in the release tarballs.⁷ Freund noted it was "not in the upstream source of build-to-host, nor is build-to-host used by xz in git."¹ Reading the repository would not have shown it.

The second half is the ceiling. Freund's same message says "the files containing the bulk of the exploit" were in obfuscated form and "committed upstream" — disguised as test files.¹ A perfectly reproducible build of the release tarball would have faithfully reproduced the backdoor — the rebuild matches its source, and the source was the problem.

The strongest argument for reproducibility here comes with its own caveat. Julien Malka argued in 2025 that NixOS could have caught xz mechanically by comparing a build from the release tarball with one from the git sources. His own footnote sets the limit: the method "only detects modifications of the tarball that have an impact on the final result," and because NixOS executables did not contain the backdoor, "we would not have discovered the backdoor." "So yes, the title is a little bit catchy, but illustrates the idea."⁷

Hold both halves at once. A reproducible build proves the app matches its source. It says nothing about whether the source is safe.

The five-minute version

The five-minute version is seven steps, and none of them involves a compiler. Find out which file you installed, look for a published reproducibility status for that version, read it honestly, and stop where the evidence stops. Most of the work is resisting a conclusion the evidence does not support.

1. Know which file you installed, and from where. A vendor site, an app store and F-Droid can hand you different files carrying the same version number.⁸ On 24 September 2026, Andy Brice — whose own software had been imitated on GitHub — put the first rule plainly: "Always download software from the vendor, where possible."⁹
2. Look for a published status. On F-Droid, every app's page carries a "Reproducibility Status" link.⁸¹⁰
3. Read the row for the version you run. The status is kept per version, and it changes.
4. If the developer says "reproducible", see what checking costs. Usually a build environment and an afternoon.
5. Do not read a download-page checksum as proof of origin. It shows you got the same file as others, not where the file came from.
6. If no status exists, record no evidence either way. Absence of a status is not evidence of wrongdoing.
7. Know where the check stops. It links the app to its source. It does not vouch for the source.

Steps 2, 3 and 6 carry most of the weight. The sections below take them one at a time.

Reading a status page: one app, sixty-three builds

A reproducibility status is a list, not a badge. On F-Droid it opens a per-version table: each row is one build its rebuilder attempted, marked with a tick if the result matched the published file and a broken heart if it did not. Read the row for your version first, then the history.

F-Droid describes the symbols this way: "✔️️ means our rebuilder reproduced the same APK file and 💔 means it did not."¹⁰ Its documentation states the aim just as plainly — to "reproduce the exact same APK as the original release."⁸

Take F-Droid's own client as the worked example. Its verification page lists 63 rebuild attempts, from 1.0-alpha0 in October 2018 to 2.0-rc0 on 12 September 2026. Forty-eight are ticks and 15 are broken hearts, counted on 25 September 2026.¹¹ Four of the broken hearts are full releases — 1.0, 1.17.0, 1.19.0 and 1.19.2. The most recent stable release in the list, 1.23.2, reproduced.

The six 2.0 test builds on that page all reproduced.¹¹ On 24 September, F-Droid announced it would begin rolling out 2.0 "after 14 test releases."¹² The announcement is about a redesign, not reproducibility. The page is where the evidence lives.

A good track record does not cover every version.

The wider data points the same way — and in a hopeful direction. A 2026 study of F-Droid by Denise Nanni and colleagues found that "only 3.5% regressed and are currently broken," while "around 18.5% of the apps have had reproducibility issues in their version history but are currently reproducible."¹³ Fixes outnumber regressions. The row you need is still the one for your version.

The thirty-minute version: when a developer says "reproducible"

A developer's claim of reproducibility is an invitation to check, and the cost of accepting it yourself is real. Most people cannot pay it. What they can do is look for a result that an independent party has already published — and understand how many independent parties that is.

Signal is the clearest mainstream case. It "has supported reproducible builds since Signal Android version 3.15.0, which was first released in March 2016," and says its process "lets you verify that the version of the app that was downloaded from the Play Store matches the source code in our public repository."¹⁴

Then it lists the steps: "You'll need to build the Docker image, run an instance of that container, compile Signal inside the container, and finally compare the compiled app bundle to the APKs that are installed on your device."¹⁴ That is an honest instruction, and it is an afternoon's work for someone comfortable with a terminal.

For everyone else, the useful move is to count the rebuilders. A tick on F-Droid means F-Droid's rebuilder agreed — one independent party, not a crowd. The consensus model needs more than one.⁵ F-Droid's 2025 post notes that the IzzyOnDroid repository shows a badge for each rebuilder.¹⁰

One tick is evidence. Several are better.

There is also a stricter standard and a different one. F-Droid calls Diverse Double-Compiling — building the same binary with two unrelated toolchains — "the gold standard," and adds that it "is a difficult standard to achieve, although quite valuable."⁸ The SLSA framework takes another route: signed records of how a build ran, which at its highest build level provide "strong confidence that the package was built from the official source and build process."¹⁵

What a matching checksum does and does not prove

A checksum on a download page proves your file matches the file the page describes. It does not prove that file was built from the public source. If the developer's build machine was compromised, the published checksum describes the compromised file — accurately. Origin needs a rebuild; a hash only compares two files.

The distinction is easy to blur because the same tool — a cryptographic hash — appears in both checks. A reproducible build is verified by comparing hashes.⁴ But the hash being compared belongs to a file somebody rebuilt from source, not to the file the developer uploaded. If you want the mechanics of comparing hashes, the bit-rot guide covers them for your own notes; the steps are the same.

Meta drew the same line in 2022 when it launched Code Verify, a browser extension for WhatsApp Web. It said the extension confirmed that the code "hasn't been tampered with or altered, and that the WhatsApp Web experience you're getting is the same as everyone else's."¹⁶

Same as everyone else's — not the same as a public source.

Common mistakes

Most mistakes here are conclusions drawn from the wrong evidence — a badge read as a rebuild, a hash read as an origin, silence read as guilt. Five are common enough to name. Each one either grants trust the evidence has not earned or withdraws it without cause.

• Treating a public repository as a verified app. The xz tarballs held code the repository did not.¹
• Treating one tick as the whole history. F-Droid's own client has broken hearts on four full releases.¹¹
• Treating a checksum as proof of origin. It proves two files match — nothing about where they came from.¹⁶
• Treating a reproducible build as a safe one. The bulk of the xz exploit sat in the repository itself.¹
• Treating no status as a red flag. Arch Linux and Debian do not show one in their package managers.¹⁰

Each of these is a shortcut. The check only works without them.

Where this check stops

A reproducible build links an app to its source, and nothing further. It cannot tell you the source is honest, it can stop being checkable years later, and many places you install software from never show it to you. Knowing these limits is part of the check, not an apology for it.

Ken Thompson made the first limit famous in his Turing Award lecture, published in Communications of the ACM in August 1984: "You can't trust code that you did not totally create yourself." And: "No amount of source-level verification or scrutiny will protect you from using untrusted code."¹⁷ A rebuild answers a narrower question than Thompson's, and that is its strength.

The second limit is time — a result can expire. Nanni and colleagues tried to rebuild 18,904 app versions that F-Droid had previously confirmed as reproducible, published between September 2018 and February 2026. Only 83% rebuilt at all, and missing dependencies caused 76% of the failures.¹³ Their conclusion is blunt: "F-Droid offers no guarantee that app reproducibility will continue to hold in the future."¹³

The third limit is visibility. F-Droid's 2025 post notes that Arch Linux and Debian "do not display information about reproducible builds in the user-facing interfaces like the package management GUIs."¹⁰ If the status is not shown to you, you have no evidence either way.

Silence is not a verdict.

The build step itself is a known target. Lamb and Zacchiroli describe how "attackers subverted the SolarWinds Orion software to inject malicious code into executables at build time," and add that "174 similar attacks have been detailed in the literature."³

How this fits the rest of a note-app audit

This check is the second step of an audit most readers start in the documentation. First you compare what an app claims with what its documents say. Then you ask whether the file you run matches the source those documents describe. Plugins and exit routes are separate questions, answered separately.

The documentation step has its own guide — which note apps actually encrypt your notes end to end — and it works entirely from published text. This piece picks up where it ends.

The opposite direction — code running inside a trusted app — is covered in why your note app's plugins are an attack surface. And what open source reliably buys you, whatever the build status, is covered in note apps that outlive the company: the ability to leave.

Each question gets its own check — and this one answers only its own.

Frequently asked questions

The first three questions are Stack Exchange titles, quoted as they were asked. The rest are the follow-ups a careful reader tends to raise after the xz story. Each answer points back to a published source rather than to anything tested here, and every figure is dated because several of them move.

"How to prove that given binary files are compiled from provided source code?"

Rebuild them from that source in the documented environment and compare the result byte for byte. If the bytes are identical, the binary corresponds to that source. That is the whole definition of a reproducible build.⁴ The question was asked on Software Engineering Stack Exchange.¹⁸

"Are reproducible builds practically possible on major app stores?"

Yes, for at least one major app. Signal publishes a procedure for checking that the version downloaded from the Play Store matches its public repository, and has supported reproducible builds on Android since March 2016.¹⁴ F-Droid links a per-version reproducibility status from every app page.¹⁰ The question was asked on Information Security Stack Exchange.¹⁹

"How can the authenticity of releases on GitHub and GitLab be ensured?"

A release file can differ from the repository. Freund found the xz release tarballs carried a line absent from git — and absent from the "source code" links, which he believed GitHub generates directly from the repository.¹ Compare release files against a rebuild, not against the repository page. The question was asked on Information Security Stack Exchange.²⁰

Is an open-source app safe because I can read the code?

No. Reading the source tells you about the source. Lamb and Zacchiroli put it directly: "trusting code is not the same as trusting its executable counterparts."³ Only an independent rebuild tells you whether the app you installed came from that source — and even then, Thompson's warning about trusting code you did not write still applies.¹⁷

Would reproducible builds have caught the xz backdoor?

No. The line that switched the backdoor on was only in the release tarballs, but the bulk of the exploit was committed to the public repository.¹ A rebuild that matched the release tarball would have reproduced the backdoor. Even the author arguing for mechanical detection concedes NixOS "would not have discovered the backdoor" and calls his title "a little bit catchy."⁷

Does a missing reproducibility status mean an app is unsafe?

No. It means there is no evidence either way. Arch Linux and Debian, which both test reproducibility, do not show it in their package managers.¹⁰ Record the gap, look for another independent party, and do not treat silence as a finding.

Is a green tick on F-Droid permanent?

No. A 2026 study tried to rebuild app versions F-Droid had once confirmed as reproducible and reached an 83% rebuild success rate; most failures were missing dependencies.¹³ The status is per version and per rebuild. Check the row for the version you run, dated.

Two acts, one link

Publishing source and shipping an app are separate acts, and only an independent rebuild that produces the same bytes connects them. Check whether one exists for the version you run, read it for that version alone, and stop where the evidence stops — at the source, which a rebuild never vouches for.

The source being public is a promise. A rebuild that matches is a receipt.

The habit that checks an app applies to notes too, and mnmnote.com keeps them as open Markdown, stored locally on your own device.