About: Go Module Proxy: Life of a query

GopherCon 2019 で発表された「Go Module Proxy: Life of a query」について、"Transparent Logs for Skeptical Clients"(
https://research.swtch.com/tlog) などを読んで理解した内容と合わせて、まとめました

Transcript

1. About: Go Module Proxy: Life of a query GopherCon 2019 報告会 Keita MIZUNO (mizkei) Merpay, Inc. Backend
2. Go Module Proxy: Life of a query
3. 発表について • 発表者 ◦ Katie Hockman ◦ 犬がかなり好き • 発表に関連するコード/資料 ◦ https://github.com/katiehockman/puppies ◦ 3つのpackageが含まれている ▪ 近所の犬を見て回る最適ルート探索する ▪ 犬の鳴き声から考えていることを教えてくれる ▪ 毎週新しいおもちゃを買うことをリマインドする
4. このpackage開発での心配事 • 再現性のないビルドを提供していること ◦ 特定バージョンで固定できていないので依存しているパッケージが 新しいバージョンを提供し始めたら壊れてしまう • 依存しているパッケージが突然ホスティングサービス上から消えてしまう こと ◦ オーナーがメンテナンスに疲弊していたら、パッケージを消してしまうかも • ホスティングサービス上のコードが何者かに変更されること ◦ 猫派の人間がいたら、悪意あるコードを入れてしまう可能性がある
5. Goにおける解決策
6. Goにおける解決策 • Modulesは再現性あるビルドを提供する • Module Mirrorsによって、パッケージが突然消える 可能性がなくなる • Checksum Databaseはホスティングサービス上のコードが 変更された可能性を知ることができる
7. Goにおける解決策 • Modulesは再現性あるビルドを提供する ⇐わかりやすい • Module Mirrorsによって、パッケージが突然消える 可能性がなくなる ⇐わかりやすい • Checksum Databaseはホスティングサービス上のコードが 変更された可能性を知ることができる ⇐ちょっと難しい
8. Go Modules
9. Go Modules • Go 1.11から提供されている機能 ◦ go.mod, go.sumを生成する ◦ GO111MODULEは1.13でもまだauto • セマンティックバージョンを提供してくれる ◦ 依存先のパッケージの依存するパッケージも minimal version selectionで 解決してくれる 再現性あるビルドはこれで保証される
10. Module Mirrors
11. GOPROXY • Go 1.13から提供される環境変数 ◦ https://proxy.golang.org,direct (カンマ区切りで2つ) ◦ https://tip.golang.org/cmd/go/#hdr-Module_downloading_and_verification • latencyとstorageの負担が減る ◦ proxy serverとはHTTPでやり取りするだけ ▪ バージョン一覧を取得して、必要なバージョンの zipファイルを落とす ▪ gitも必要ない go command Proxy (Cache) GitHub GitLab Bitbucket ...
12. Module Mirrors • proxyで経由する中でキャッシュしていく ◦ 各種リクエストやzipのダウンロードの速度もよくなる もし突然ホスティングサービス上からコードが 消えてなくなっても、mirrorにキャッシュされているので 取得できなくなることはない (ただ、まだ改ざんの検知はそのパッケージのgo.sumでのみ)
13. Checksum Database
14. Merkle Tree • ハッシュ木 ◦ 単純にパッケージパスとバージョンに対して、 go.sum持っているだけでは 改ざんに気づくことが困難なため利用する ▪ 包含 • 特定レコード(go.sum)がその木に含まれていることは証明できる ▪ 一貫性 • 特定レコード(go.sum)は記録されたあとに変更されることはない
15. • rootまでgo.sumのhashを計算していく Transparent Log 0 0 1 2 1 3 4 2 5 6 3 7 0 1 0 go.sum h(L,K): Level LのNumber Kのhash H(h1,h2): h1とh2から生成されるhash h(3, 0) = H(h(2, 0), h(2, 1)) = H(h(2, 0), H(h(1, 2), h(1, 3))) = H(h(2, 0), H(h(1, 2), H(h(0, 6), h(0, 7)))) = H(h(2, 0), H(h(1, 2), H(h(0, 6), hash(record 7)))) ※一部だけ展開しています Level0 Level1 Level2 Level3 record
16. Checksum Database • 環境変数GOSUMDBで指定されたサーバーに問い合わせる ◦ レコードナンバー、go.sum、rootのhashが取得できる ▪ rootまでhashを計算していくことでgo.sumを検証できる ◦ 誰かが初めて利用したときのhashで検証ができる ▪ 各パッケージの最初の利用より前のデータを利用できる ◦ 包含、一貫性の性質があるため、悪意ある存在が DBを運用するのが困難 ▪ 特定クライアントに特定パッケージの偽 go.sumを提供しようとしても、 rootまでのhashをクライアントが検証できる ▪ もし、悪意ある存在が偽情報を渡すことができたとしても、一貫性のため その偽treeを維持し続けるのは困難であり、監視者によって treeを検証 されるとすぐに嘘が明らかになる
17. Checksum Database record 4に記録されたあるパッケージPの バージョンVを検証をする場合 /lookupで下記を取得する - rootのhash - record number(この場合4) - record 4のgo.sum 赤い部分をクライアントが計算していく 0 0 1 2 1 3 4 2 5 6 3 7 0 1 0 package P, version Vのgo.sum
18. Checksum Database 青い部分のhashがあれば、rootまで計算可能 API: /tile 計算回数と必要なhash値は高々、木の高さ(logN)の 分だけ rootまで計算したhashがAPIで取得したhashと 一致すれば、そのrecordのgo.sumがtreeに 存在していることになる 0 0 1 2 1 3 4 2 5 6 3 7 0 1 0
19. Checksum Database cacheはtileという固まりに分割することで サーバーとローカルの容量を消費しすぎない ある高さで区切って、その中で一番下の Level のみcacheする(図の ) 同一tile内の上のLevelのhashは計算する tileの高さは実際の実装では8を想定 0 0 1 2 1 3 4 2 5 6 3 7 0 1 0
20. Checksum Database treeは新しいデータを追加していくのみ 一度登録されたgo.sumは消えることはない (追加の仕方自体は色々ある) もし悪意あるDB管理者が偽のtreeを作った としても、そのtreeを永遠に保持しなければならな いので、嘘を付き続けるコストが 非常に高い すべてのクライアントに偽情報を提供しな ければならないので、誰かに気づかれる 0 0 1 2 1 3 4 2 5 6 3 7 0 1 0 8 1 0
21. Summary
22. Goにおける解決策 • Modulesは再現性あるビルドを提供する ◦ semantic version ◦ minimal version selection • Module Mirrorsによって、パッケージが突然消える 可能性がなくなる ◦ mirrorのserverにコードが保存される ◦ localがすべき処理もダウンロードする量も抑えることができる • Checksum Databaseはホスティングサービス上のコードが 変更された可能性を知ることができる ◦ "誰か"が初めて利用した時のgo.sumで検証ができる ◦ DB自体も改ざんが難しい
23. “Go Modules” “Modules Mirrors” “Checksum Database”
24. Thanks!!