# 「AMA: Go を使用した安全性と信頼性の高い開発」のまとめメモ

TODOになってるところは書きかけです。

https://events.google.com/io/session/7b7e7dd8-57a5-4459-a96e-1494d09efbe6

## ファジング

https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md に関連した話。このプロポーザルは読んでないし、ファジングを使ったこともないので間違ったまとめになってるかもしれない。

- 6:00 “What are some new things coming to Go that help with end-to-end security?”
- 「E2Eのセキュリティを向上させるようなGoの新機能について教えてください」
- この質問の回答の後半で言及された。
- ファジングの概要と、この機能がGo本体でサポートされることの意義について。
- 9:14 How long do you think it will be before the new go fuzzing proposal uncovers bugs in hardware?
- 「Goの新しいファジングの提案でハードウェアのバグが見つかるのはいつごろになりそうですか？」
- （ハードウェアのバグ、というのがよくわからない。なんか誤解してるかも）
- ファジングは遠からずリリースされる見込み
- ベータ版のうちから使ってほしい
- coverage-guided fuzzingもサポートしてるよ
- （生成した入力がコードのどの部分をカバーしてるかを確認して、カバー率を上げるような入力を生成する的な何からしい）
- 14:30 Will there be a way to seed fuzzing or trace the seed for a fuzz so errors can be repeated?
- 入力は簡単に再現できる
- （そのほかにも何か話されてたけどよくわからなかった）
- 21:25 Will fuzzing be more than just type registries with candidate values per type? What kind of smarts are in fuzzing?
- type registryというのはよくわからない
- 今は基本的な型だけをサポートしているが、今後はより複雑な型もサポートする予定

## サードパーティーのライブラリ

- 2:25 How does Go provide dependency management?
- go.modというファイルで依存ライブラリの名前とバージョンを管理している
- 4:00 How do I choose dependencies for my project?
- pkg.go.devはサードパーティーライブラリを選ぶための情報を提供している
- その情報は「人気」と「品質」と「安定性」の3つに分けられる
- （それぞれの定義とか、なぜそれが重要なのか、という話が続く）
- 6:00 What are some new things coming to Go that help with end-to-end security?
- 「E2Eのセキュリティを向上させるようなGoの新機能について教えてください」
- Goの脆弱性が見つかったとき、それが自分のアプリケーションに影響するかどうか知ることができる仕組みを作ろうとしている
- 公開された脆弱性を収集するデータベース
- そのデータベースにアクセスして自分のコードベースが影響を受けるかを確認するgo auditというツール
- 脆弱性のあるバージョンのライブラリを使っているかどうかだけではなく、脆弱性があるコードを呼び出しているかどうかまで検出してくれる
- 10:33 Are there any plans to limit what dependencies can do? For example, declaring that a dependency package can’t make network calls or execute child processes?
- そういう計画はない
- Goはメモリを直接読み書きできるので、そういった制限を実装するの難しい
- 以前はsafe compiler modeというのがあったけどgo 1.12で削除された
- gVisorみたいなサンドボックスを使ったほうがいい
- とはいえSpectreのようなCPUの脆弱性を突かれればサンドボックスも意味がない
- 12:10 How to be sure that the public Go library that I use is secure and doesn't contain backdoors or something else?
- テストコードの有無を確認するとか、pkg.go.devのバージョン履歴を確認するとか、脆弱性データベースを参照するとか
- （テストコードの有無はあまり関係ないような気がする。解釈間違ってるかも）
- 信頼できる人が作っているか、利用者の数も指標になる
- とはいえ、バックドアがないことを確かめる確実な手立てはない
- Goには依存をできるだけ少なくするという文化がある
- 依存が少なければそれだけ安全になる
- 23:30 What are some features on pkg.go.dev that can help me evaluate if a project is stable?
- バージョンが1.0に到達していれば安定していそう
- 古いバージョンを削除していれば（？）pkg.go.devの画面には黄色い警告マークが出る
- 今後、pkg.go.devにはパッケージのAPIの履歴を表示したり、バージョン間の差異を表示する機能を追加する予定
- 24:40 Why do Go modules require SemVer?
- TODO
- 27:26 How often do you have to deprecate older crypto libraries? Do these deprecations break older versions of Go?
- deprecateしたが削除してはいないので、互換性を壊すことはない
- エディタとかで「deprecatedな機能を使っているよ」という警告は出るはず

## その他

- 17:00 What is the best IDE for secure Go development?
- JetBrains製のGoLandについてはコメントできないので、ここではVSCodeやその他のエディタについて話したい
- LSPを使っているエディタならgoplsをバックエンドにしているので機能は変わらない
- ただし、VSCodeはユーザーが多いので、goplsがサポートしていないgolangci-lintなどのlinterを直接サポートするプラグインがあったりする
- （このへんよく聞き取れなかったので間違ってるかも）
- VSCodeにはtrusted workspaceという仕組みは開発時のセキュリティを高めるのに役立つ
- 信頼できないGoのコードが拡張にうっかり実行されないようにガードする仕組み
- （セキュリティの高いコードを書くための仕組みではない）
- Goでは依存を解決してビルドしてソースコードを開くだけではコードが実行されないように設計されている
- 19:30 Does Go have a debugger? What are upcoming new features for debugging?
- delveというデバッガがある
- delveをDebug Adapter Protocolというデバッガの共通プロトコルに対応させようというプロジェクトが進行中
- 29:00 What is one thing you would recommend checking out for Go?
- TODO