#81227 x/crypto/openpgp: isolate, tag, delete

AIによる要約であり、誤りを含む場合があります。

概要

2021年から凍結・非推奨になっている golang.org/x/crypto/openpgp パッケージを、x/crypto モジュールから正式に取り除く提案です。手順は Go チームが過去にも使ってきた「isolate, tag, delete」で、該当パッケージを独立したサブモジュールに切り出し、その時点の状態にタグを付けたうえで、x/crypto 本体からコードを削除します。

ステータス変更

likely_accept → accepted
2026年9月30日の Proposal Review では、@aclements が次の2点を論点として示しました。

一部のセキュリティスキャナは、openpgp の脆弱性を「x/crypto モジュールを使うすべてのコードの脆弱性」として扱ってしまう。
コードを削除すれば、保守されているコミュニティ fork への移行を促せる。
10月1日に likely accept となり、その後も異論が出なかったため、10月8日に「No change in consensus」として accepted になりました。

技術的背景

現状の問題点

x/crypto/openpgp は #44226（2021年）で凍結・非推奨になりました。その時点では、セキュリティ修正のみ受け付けて「パッケージは削除しない」という方針でした。
現在は脆弱性情報 GO-2026-5932 で「設計上安全でなく、既知の問題が多数あり、保守されておらず、使うべきではない」と明記されています。#79841（elgamal.Decrypt が細工された入力で panic する DoS）のような報告や修正 PR も受け付けていません。
それでもコードは x/crypto リポジトリに残っています。そのため Trivy や osv-scanner などのスキャナが、openpgp を使っていない ssh や acme などの利用者まで、モジュール単位で「脆弱」と報告してしまいます（#80347）。

提案された解決策

golang.org/x/crypto/openpgp に専用の go.mod を置き、独立したモジュールとして切り出す（isolate）。
切り出したモジュールに凍結版としてタグを付け、Deprecated コメントを付ける（tag）。
x/crypto 本体からコードを削除する（delete）。

これによって何ができるようになるか

openpgp を使っていない x/crypto 利用者（ssh、acme、chacha20poly1305 など）が、スキャナの誤検知に悩まされなくなります。
openpgp を使っているコードも、切り出されたモジュールの凍結版でそのままビルドできます。go get -u を実行すると、そのサブモジュールが自動で go.mod に追加されます。
go get 実行時に非推奨の警告が表示されるため、github.com/ProtonMail/go-crypto のような保守されている fork へ移行するきっかけになります。

コード例

// Before: x/crypto 全体に依存し、openpgp もその中に含まれている
// go.mod
require golang.org/x/crypto v0.55.0
// → openpgp を import していなくても、スキャナが GO-2026-5932 を報告する
// After: go get -u 後の go.mod のイメージ（openpgp を import している場合）
require (
	golang.org/x/crypto v0.xx.0                 // openpgp を含まない
	golang.org/x/crypto/openpgp v0.x.x-deprecated // 凍結された切り出しモジュール
)
// go: module golang.org/x/crypto/openpgp is deprecated: ... と警告される
// 推奨: 保守されている fork へ移行する
import "github.com/ProtonMail/go-crypto/openpgp"

上の openpgp モジュールのバージョン表記は、過去の x/tools/go/vcs の前例（v0.1.0-deprecated）から類推したもので、実際のタグはまだ確定していません。

議論のハイライト

@FiloSottile は、非推奨になったパッケージが削除されるのは通常の流れではないと補足しました。「非推奨になるとすぐにコードがコンパイルできなくなる」という誤解を避けるための指摘です。あわせて、go get -u で切り出し地点を越えたときに何が起きるかを質問しました。
@seankhliao は、x/tools/go/vcs を切り出したときの実例を示しました。go get -u を実行すると golang.org/x/tools/go/vcs v0.1.0-deprecated が自動で追加され、非推奨の警告も表示されるので、既存コードは凍結版のままビルドを続けられます。
削除の目的は、出来の悪いスキャナへの対策だけではありません。Go チームと利用者が保守されていないコードを目にしなくて済む、という点も挙げられました。
Proposal Review では、コードの削除が保守されている fork への移行を促す手段になる、という点が評価されました。
#44226 の「削除はしない」という方針を、5年後に正式に改める判断になりました。保守されないままセキュリティ報告が続いていることと、スキャナの誤検知が実際に問題になっていることが背景にあると考えられます。

Go Proposal Weekly Digest

x/crypto/openpgp: isolate, tag, delete

要約

概要