オープンソースVPNクライアント:コードが証明できること、できないこと
公開リポジトリはソースコードについての証拠であり、あなたがインストールしたビルドやその背後のサーバーについての証拠ではありません。リリースを照合し、そのうえでレビューの範囲を広げてください。
ソースは公開され、ライセンスも整っており、それでも接続を端から端まで検証することはできません。この隔たりはありふれたもので、醜聞ではありません。コードを公開すると、招かれていない人々が一つの構成要素を検査できるようになり、これは現実的で珍しい性質です。 そこから、インストールしたバイナリがそのコードに由来するとは言えませんし、提供事業者が向こう側で動かしている何かが検証されたとも言えません。
構成要素と製品を切り分ける
オープンソースという表示を帯びうるものは四つあり、すべてが開いていることはまれです。人々が指すのはクライアントアプリケーションです。その下のプロトコル実装は別の成果物で、ライブラリのこともあればツリー内のコードのこともあります。サーバーソフトウェアが三つ目で、事業者自身の基盤、アカウントポータル、サポート用の道具が四つ目です。それぞれが独立に開いたり閉じたりしえます。
したがって「うちのアプリはオープンソースです」という言い方は最初の項目を述べ、残りには触れていません。これは不誠実というより範疇のずれであり、有用な問いは、どのリポジトリのどのタグが、あなたが頼っている構成要素に対応するのかというものです。
この区別は、同じ開いたクライアントを持つ二つの製品が大きく異なる保証を提示しうる理由も説明します。クライアントはあなたが確かめられる部分であり、運営者の振る舞いは別の手段で評価しなければならない部分です。
インストール済みビルドを公開タグに照合する
リポジトリは意図の記録であり、ディスク上のバイナリは実行されるものです。その隔たりを閉じるのは機械的な作業で、ダウンロードページが宣伝したものではなく、実際に何が導入されているかを特定することから始まります。
| 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 |
パッケージのメタデータは版と出所を教えてくれ、古いパッケージや差し替えられたパッケージという単純な事例を排除します。しかしそのパッケージがどうコンパイルされたかは教えず、まさにその問いに答えるために再現可能ビルドが存在します。 再現可能ビルド は、独立した第三者が同じソースから再構築し、出力をバイト単位で比較することを可能にし、不一致が疑いではなく証拠になります。
完璧な一致でさえ、人が期待するほどは証明しません。成果物がソースとビルド手順に対応することは示しますが、ソースに欠陥がないことや、使われた道具の連鎖が信頼できたことは示しません。どちらも知る価値はありますが、別の主張です。
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg症状はふつうどこから始まるか
この読み物のきっかけになる不満は、めったに「コードが閉じている」ではありません。ふつうは具体的な観察です。予期しない場所に通信するクライアント、リリースノートと異なる版、トンネルが必要とする以上を求めるサポート手続きであり、これらの点はそれぞれ別の構成要素を指しています。
クライアントからの予期しない通信はクライアントのソースコードの問いであり、接続を開くコード経路を読むことで答えられます。版の不一致はパッケージングの問いです。身分証明書を求めるサポート手続きはアカウント体系の問いであり、クライアントの監査をいくら重ねても解決しません。
構成要素に名前を与えると、漠然とした不信が具体的な確認に変わります。具体的な確認には答えられ、論じられ、あるいは決着をつけられます。代わりに残るのは、次の一歩のない永続的な疑念です。
レビューが届かない範囲と、代わりにすべきこと
事業者のサーバー上の保持はクライアントの手の届かないところです。請求ポータル、不正検知の外部事業者、添付を保存するサポート窓口の振る舞いも同じです。クライアントのレビューを「サービスを監査した」まで引き伸ばすと、証拠が支えない主張になります。
運営者が保持と要請について公表している内容を読み、日付を記録し、測定ではなく利害を持つ当事者の声明として扱ってください。それは弱い形の証拠であり、違いを明示するほうが、語り直すときに格上げするより役に立ちます。
そのうえで手持ちのものを複数の入力の一つとして使ってください:導入されたリリースの同一性、 ソフトウェアが保守されているか、クライアントの設定、運営者が自らの体系について語ること。オープンなコードはその評価を一点で強めます。残りを置き換えるものではありません。
監査の主張は常にその構成要素と版を名指しすべきです。どのリポジトリのどのビルドを調べたのか言えない報告書は、製品ではなく意図を述べているのです。