開発に加わる

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

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

コードベースの構成

• Go の、import 可能なパッケージ群。API を後付けした一枚岩ではありません。 強制経路はライブラリで、リファレンスのバイナリは薄い層です。policy、 swg、eastwest だけを自分の実装に取り込むこともできます。
• Swift による macOS の Network Extensionと、 Windows の WFP エージェント＋自社製 callout ドライバ。 ここは実機が要る部分です —— OS レベルのフロー捕捉は、単体テストだけでは存在を確かめられません。 なおドライバはカーネルモードで、まだ attestation 署名を得ていません。したがって今これに手を入れるには、 機械を testsigning モードにする必要があります（理由）。
• cgo でネイティブライブラリを結合する egress エンジン。 全面復号の配備が単一バイナリではなく2プロセスになる理由であり、第三者ライセンスの一覧を 手で維持している理由でもあります —— 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 による模倣は bot 対策が既に弾いている 指紋なので、そこへ退避すると「broker が落ちている」という1つの読める失敗が、 宛先ごとにばらけて誰にも診断できない故障に化けます。通信を失敗させることが機能です。
• ライセンスが通信を止められるようにする変更。ライセンスはその範囲を超える 新規登録を拒否し得ますが、ステアリングを止めること、流れている通信を切ること、 Edge を停止させること、機能を無効化することはできません。 現状はご自分で確認できます —— それを行い得る述語は実装されていますが、 自分のテスト以外に呼び出し元が1つもありません。この不在は未完成ではなく、 意図されたものです。
• 検査を通すために既定値や文書を弱める変更。検査が落ちたときは、 実装が誤っているか、主張が広すぎたかのどちらかです。どちらも直すべきは対象の方で、 それについての表明の方ではありません。
• テストからも実行例からも到達できない機能。このプロジェクトの主張は 「主張が確かめられること」そのものです。誰も動かせない機能は、誰も確かめられない主張です。

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

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

リポジトリは 2026-09-01 に github.com/lantern-networks/dsse-core で公開されます。それまではビルドする対象がまだありません。 何をどこに持ち込むか。