Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/permissionlesstech/bitchat/llms.txt

Use this file to discover all available pages before exploring further.

This page is about a specific risk: getting a copy of Bitchat that someone has modified. It matters because the repository has been the target of takedown demands. When a repository or releases page becomes unavailable, mirrors appear — and people who need the app during a shutdown install whatever they can find. That is exactly the moment a trojaned build reaches the people with the most to lose. A modified Bitchat can log plaintext, ship keys off the device, or weaken the mesh, and it will look and behave normally while doing it.
A modified build has no reason to look different. It can pass every visual and functional check while silently exfiltrating messages or keys. The only protection is verifying source before you build.
The honest summary is short: source can be verified; compiled apps cannot, unless they come from the App Store. Everything below elaborates on that.

​
Trust Hierarchy

In order of how much verification is possible:
  1. App Store — Apple verifies the developer signature, and the binary cannot be altered without breaking it. This is the only channel where a compiled build is verifiable end to end, and it is the right recommendation for almost everyone.
  2. Build from verified source — requires a Mac and Xcode, but gives you the strongest possible guarantee if you can do it. See the sections below.
  3. Compiled build from any other source — not verifiable. See Unverifiable Builds.

​
Verifying Source

Every tagged release has a SOURCE-MANIFEST.txt produced by .github/workflows/source-manifest.yml. It records the tag, the commit, the git tree hash, and a SHA-256 for every tracked file.
Keep the downloaded manifest outside the source tree — for example at /tmp/SOURCE-MANIFEST.txt. A stray copy inside the checkout will itself trip the completeness checks below.
From the root of the source you obtained, with the manifest saved at /tmp: 
# From the root of the source you obtained, with the manifest at /tmp
grep -v '^#' /tmp/SOURCE-MANIFEST.txt > /tmp/files.sha256
shasum -a 256 -c /tmp/files.sha256
Any FAILED line means that file differs from the released source. Investigate before building.

​
Check for Extra Files

The hash check alone is not sufficient. shasum -c verifies only the files the manifest lists and says nothing about files it does not list. The Xcode project compiles every source file present in the tree automatically, so a hostile mirror can pass the hash check by leaving every listed file intact and adding one. Confirm nothing extra is present: 
# The manifest's path list must match the tree exactly — no missing files, no extras
grep -v '^#' /tmp/SOURCE-MANIFEST.txt | sed 's/^[0-9a-f]*  //' | LC_ALL=C sort > /tmp/manifest-paths
find . -type f ! -path './.git/*' | sed 's|^\./||' | LC_ALL=C sort > /tmp/actual-paths
diff /tmp/manifest-paths /tmp/actual-paths   # must print nothing
In a git checkout, the same assurance is one command — it also catches extra files, because they show as untracked. The --ignored flag matters: .gitignore covers paths like build/, and plain git status would not report a planted file there even though Xcode compiles it all the same: 
git status --porcelain --ignored      # must print nothing before you build

​
Git Tree Hash

The single value that covers the whole tree is the git tree hash recorded in the manifest header: 
git rev-parse HEAD^{tree}   # must equal the "tree:" line in the manifest
Note that the tree hash covers tracked content only — it does not see untracked files sitting in the working directory. That is why the completeness checks in the previous section must come first.

​
Attestation Verification

The manifest carries a provenance attestation tying it to the GitHub Actions workflow run that produced it. This means a manifest handed to you alongside a mirror is itself checkable — without this step, whoever provides the source could provide a matching manifest: 
gh attestation verify /tmp/SOURCE-MANIFEST.txt --repo permissionlesstech/bitchat
This step is what makes the verification resistant to a hostile mirror.

​
If the Manifest Is Unavailable

Compare against a trusted commit hash instead. Git object hashes cover content and history, so if you can obtain the expected commit hash through any channel you trust — a second mirror, a maintainer post elsewhere, or someone who cloned earlier — then: 
git fetch <mirror> --tags
git rev-parse v1.2.3        # compare against the hash you trust
git verify-tag v1.2.3       # if the tag is signed
A mirror whose history matches a commit hash you trust from an independent source is a faithful mirror.

​
Unverifiable Builds

If you have an .ipa, an .apk, or a Mac app from a forum, a chat group, a file locker, or any mirror, you cannot verify it. There is no published signing key for compiled builds and no reproducible-build pipeline, so there is nothing to compare a binary against. What to do, in order of preference: install from the App Store; build from verified source; or, if neither is possible, treat that build as untrusted — assume anything you type into it may be disclosed, do not use it for anything sensitive, and do not carry it somewhere its presence on your device is itself a risk.

Build docs developers (and LLMs) love

Get started for freeTalk to us