#81227likely_accept
x/crypto/openpgp: isolate, tag, delete
新規提案
要約
AIによる要約であり、誤りを含む場合があります。
概要
golang.org/x/crypto/openpgp パッケージ(2021年から凍結・非推奨)を独立したサブモジュールとして切り出し、タグを付けてから x/crypto 本体のリポジトリから削除する提案です。提案者は Go チームの @seankhliao です。
ステータス変更
(新規) → likely_accept
2026年9月30日の Proposal Review Meeting で @aclements が論点を2つ挙げました。
- 一部のセキュリティスキャナは、x/crypto/openpgp の脆弱性を「x/crypto モジュールに依存するものすべての脆弱性」として扱ってしまう。
- コードを削除すれば、メンテナンスが続いているフォークへの移行を促せる。
これらを踏まえ、10月1日に「isolate, tag, and delete(切り出し、タグ付け、削除)」の形で likely accept と判断されました。現在は Final Comment Period に入っています。
技術的背景
現状の問題点
- x/crypto/openpgp は #44226(2021年)で凍結・非推奨になりました。ただし当時の告知には「パッケージは削除しない」と書かれていました。
- 2026年に公開された脆弱性情報 GO-2026-5932 では、このパッケージを「設計上安全でなく、既知のセキュリティ問題が多数あり、メンテナンスされておらず、使うべきではない」と説明しています。
- Go チームはこのパッケージへのバグ報告や修正を受け付けていません。例として、elgamal.Decrypt に細工した入力を渡すと panic する報告(#79841)もクローズされています。
- それでもコードは x/crypto リポジトリに残っています。そのため、Trivy や osv-scanner などのスキャナが、ssh や acme しか使っていないプロジェクトまで「x/crypto に脆弱性あり」と誤検知しています(#80347)。
提案された解決策
x/tools/go/vcs などで前例のある「モジュールのカーブアウト(carve-out)」を使います。手順は次のとおりです。
golang.org/x/crypto/openpgpを独立したモジュールにする(isolate)- そのモジュールに凍結版のタグを付ける(tag)。前例では
v0.1.0-deprecatedのような形です。 - x/crypto 本体からコードを削除する(delete)
これによって何ができるようになるか
- 誤検知の解消: x/crypto の他のパッケージ(ssh、acme、bcrypt など)だけを使うプロジェクトが、openpgp の脆弱性で誤ってフラグを立てられなくなります。
- 既存コードは引き続きビルドできる: openpgp を import しているコードで
go get -uを実行すると、切り出された凍結版モジュールが go.mod に自動で追加されます。そのためビルドは壊れません。 - 移行を促す: 本体リポジトリからコードが消えるので、ProtonMail/go-crypto などメンテナンスされているフォークへ移行するきっかけになります。
コード例
// Before: x/crypto モジュールに openpgp が同梱されている
// go.mod
require golang.org/x/crypto v0.55.0
// → ssh しか使っていなくても、一部スキャナが GO-2026-5932 を報告する
// After: openpgp を import しているコードで go get -u を実行すると
// (x/tools/go/vcs の前例と同様の挙動)
// go: module golang.org/x/crypto/openpgp is deprecated: ...
// go: added golang.org/x/crypto/openpgp v0.1.0-deprecated
require (
golang.org/x/crypto vX.Y.Z // openpgp を含まない
golang.org/x/crypto/openpgp v0.1.0-deprecated // 凍結版(バージョンは推測)
)
// 推奨される移行先の例: メンテナンスされているフォーク
import "github.com/ProtonMail/go-crypto/openpgp"
openpgp 用のタグ名はまだ決まっていません。上の例のバージョンは前例をもとにした推測です。
議論のハイライト
- 非推奨の通常の帰結ではない: @FiloSottile は、非推奨になったパッケージは普通は削除されないと指摘しました。非推奨化のたびに「コードがすぐ動かなくなる」と心配する利用者を安心させるための補足です。今回は例外的な対応になります。
- go get -u の挙動: @FiloSottile が「カーブアウトされたパッケージを使っている状態で更新すると、サブモジュールは自動で追加されるのか」と質問しました。@seankhliao は x/tools/go/vcs の実例を示し、
v0.1.0-deprecatedが自動で追加され、非推奨の警告も表示されることを確認しました。 - 目的: 主な目的は出来の悪いスキャナによるモジュール全体の誤検知を避けることです。@seankhliao は、それに加えて Go チームや利用者がこのコードを目にしなくて済むという利点も挙げています。
- フォークへの移行促進: レビュー会議では、削除が保守されたフォークへの移行を後押しすると評価されました。