開発に加わる

いちばん役に立つのは、パッチではありません。こちらが持っていない環境で DSSE を動かし、 何が壊れたかを伝えることです。

パッチを軽んじているのではありません。強制コアを公開している理由そのものです。 セキュリティのデータプレーンは、実環境と実際の攻撃に晒されて初めて頑健になります。そして それを1人の書き手が再現することはできません。どのネットワークにも、こちらのラボには無い ミドルボックスや、キャプティブポータルや、ピン留めされたアプリや、証明書ポリシーがあります。 そこから届く正確な不具合報告は、ここでは多くの新機能より価値があります。

コードベースの構成

• Go の、import できるパッケージ群。API を後付けした一枚岩ではありません。 強制経路はライブラリで、リファレンスのバイナリは薄い層です。policy、swg、 eastwest だけを自分の実装に取り込むこともできます。
• Swift による macOS の Network Extensionと、 Windows の WFP エージェントおよび自社製 callout ドライバ。ここは実機が要る部分です。 OS レベルのフロー捕捉は、単体テストだけでは存在を確かめられません。私たちが配るドライバには Microsoft の attestation 署名が付いていますが、あなたがコンパイルしたものには付きません。 カーネル側に手を入れるなら、機械を testsigning モードにする必要があります。 署名はバイナリ1つずつに付くもので、それこそが署名の意味です（詳しく）。
• 標準の Edge ビルドは Go の HTTP・TLS 実装で egress を担います。 ソースには curl-impersonate エンジンも含まれますが、利用には追加のビルド・設定が必要です。 cgo で組み込む場合はネイティブライブラリが必要になります。 それらは Go の依存走査の対象外なので、バージョンとライセンスを別途管理します。

ビルドする

go build ./...
go vet ./...
go test ./...

# Windows のステアリングエージェントはクロスコンパイルできます:
GOOS=windows GOARCH=amd64 go build ./clients/windows-wfp/steer/

# macOS の Network Extension（Swift 6 のツールチェーンが要ります）:
cd clients/macos-network-extension && swift build && swift test

CI は Pull Request ごとに同じ検査を走らせます。コントリビューションは Developer Certificate of Origin の下で受け付けるので、 git commit -s で全コミットに署名を付けてください。

良い変更の形

• 1つの Pull Request につき、論理的な変更は1つ。
• 挙動を変えるならテストを。直そうとしている不具合をそのテストが捕まえられるなら、 パッチとしての価値はテストの側にあります。
• fail-closed を fail-closed のままに。リファレンスの Edge とコントロールプレーンは 平文で応答してはならず、検知や観測が強制を自動でバイパスしてもいけません。
• 変更後も本当であるコメント。正確なコメントは変更の一部です。

受け入れられない変更と、その理由

レビューで初めて知るのではなく、先に書いておきます。いずれも一見すると明らかな改善に見える 種類のものだからです。

• 障害時に、選択された egress 実装を黙って切り替える変更。 標準構成は Go です。運用者が curl-impersonate を明示的に有効にした場合は、その障害を Go への自動切り替えで隠してはいけません。どちらの構成でも、接続を回復するために 検査や証明書検証を自動でバイパスしてはいけません。
• ライセンスが通信を止められるようにする変更。ライセンスは範囲を超える新規登録を 拒否し得ますが、ステアリングを止めることも、流れている通信を切ることも、Edge を停止させることも、 機能を無効化することもできません。現状は自分で確認できます。それを行い得る述語は 実装されていますが、自分のテスト以外に呼び出し元が1つもありません。この不在は 未完成ではなく、意図したものです。
• 検査を通すために既定値や文書を弱める変更。検査が落ちたときは、実装が誤っているか、 主張が広すぎたかのどちらかです。どちらも直すべきは対象のほうで、それについての表明の ほうではありません。
• テストからも実行例からも到達できない機能。このプロジェクトの主張は「主張が確かめられること」 そのものです。誰も動かせない機能は、誰も確かめられない主張です。

返答の速さについて、正直なところ

ごく小さな体制で、非同期に維持しています。Pull Request が数日置かれることはあります。 大きな変更の前に Issue を立てておく価値はあります。手続きとしてではなく、 良いものを書いたのに方針と合わないということが現実に起こり得るからで、 それを後から知るのは誰にとっても割の合わない取引だからです。

リポジトリは github.com/lantern-networks/dsse-core です。 何をどこに持ち込むか。