Open Source VPN Client: What the Code Proves and What It Cannot
A public repository is evidence about source code, not about the build you installed or the servers behind it. Match the release, then widen the review.
Source published, licence clean, and the connection still cannot be verified end to end. That gap is ordinary, and it is not a scandal. Publishing code makes one component inspectable by people who were not invited, which is a real and unusual property. It does not follow that the binary you installed came from that code, or that anything the provider operates on the other side has been reviewed at all.
Separate the component from the product
Four things can carry the open-source label, and they are rarely all open. The client application is the one people mean. The protocol implementation underneath it is a different artefact, sometimes a library and sometimes in-tree code. The server software is a third, and the provider's own infrastructure, account portal and support tooling are a fourth. Each can be open or closed independently.
Statements like "our app is open source" therefore describe the first item and leave the rest unaddressed, which is not dishonesty so much as a category slip. The useful question is which repository, at which tag, corresponds to the component you are relying on.
That distinction also explains why two products with identical open clients can offer very different assurances. The client is the part you can check; the operator's behaviour is the part you have to assess by other means.
Match the installed build to the published tag
A repository is a record of intent; the binary on your disk is the thing that runs. Closing that gap is a mechanical exercise, and it starts with identifying exactly what is installed rather than what the download page advertised.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
Package metadata tells you the version and the origin, which rules out the trivial case of a stale or substituted package. It does not tell you how that package was compiled, which is the question reproducible builds exist to answer. Reproducible builds let an independent party rebuild from the same source and compare the output byte for byte, so a mismatch becomes evidence rather than suspicion.
Even a perfect match proves less than people hope. It shows the artefact corresponds to the source and the build recipe, not that the source is free of defects, and not that the toolchain used was trustworthy. Both remain worth knowing, but they are different claims.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgWhere a symptom usually starts
The complaint that prompts this reading is rarely "the code is closed". It is usually a specific observation: a client that phones somewhere unexpected, a version that differs from the release notes, or a support process that asks for more than the tunnel should need. Each of those points at a different component.
Unexpected network traffic from the client is a client-source question, and it is answerable by reading the code path that opens the connection. A version mismatch is a packaging question. A support process that requests identity documents is an account-system question, and no amount of client auditing will resolve it.
Naming the component turns a vague distrust into a specific check. A specific check can be answered, argued with or closed. The alternative is a permanent suspicion with no next step.
What the review cannot reach, and what to do instead
Retention on the provider's servers is outside the client's reach. So is the behaviour of a billing portal, a fraud-checking vendor or a support desk that keeps attachments. A client review that gets stretched into "we audited the service" makes a claim the evidence does not support.
Read what the operator publishes about retention and requests, note the date, and treat it as a statement by an interested party rather than a measurement. That is a weaker form of evidence, and being explicit about the difference is more useful than upgrading it in the retelling.
Then use what you have as one input among several: the identity of the installed release, whether the software is maintained, how the client is configured, and what the operator says about its own systems. Open code strengthens that assessment at one point. It does not replace the rest of it.
An audit claim should always name its components and versions. If a report cannot say which repository and which build it examined, it is describing an intention rather than a product.