GitHubの公式ドキュメント更新「Revert “Update dotnet nuget verify docs for CRL and OCSP URL verbosity output…”」は、GitHubそのものの機能変更ではなく、GitHub上の dotnet/docs リポジトリで公開されている .NET CLI ドキュメントの修正です。結論から言うと、dotnet nuget verify の出力に CRL URL と OCSP URL が表示されるという説明が、リリース済みSDKの挙動と合わないため取り消されました。CI/CD、GitHub Actions、ログ解析、NuGetパッケージ署名検証を運用しているチームは、「ドキュメントに載っていない＝検証不要」ではなく、「SDKごとの実出力を確認し、自動化を壊れにくくする」ことが重要です。(GitHub)
GitHubの公式ドキュメント更新で何が変わったか
今回確認すべきポイントは、追加ではなくリバートである点です。
2026年4月28日にマージされた dotnet/docs のコミットでは、dotnet-nuget-verify.md から次の説明が削除されました。対象は、dotnet nuget verify の --verbosity ごとの出力内容を示す表です。(GitHub)
| 削除された項目 | 以前の説明上の意味 | 今回の扱い |
|---|---|---|
Author/Repository Certificate -> CRL URL | 署名者またはリポジトリ証明書のCRL URLが出力される | ドキュメントから削除 |
Author/Repository Certificate -> OCSP URL | 署名者またはリポジトリ証明書のOCSP URLが出力される | ドキュメントから削除 |
Timestamp Certificate -> CRL URL | タイムスタンプ証明書のCRL URLが出力される | ドキュメントから削除 |
Timestamp Certificate -> OCSP URL | タイムスタンプ証明書のOCSP URLが出力される | ドキュメントから削除 |
Requires .NET SDK 10.0.300 or later の脚注 | これらの項目が .NET SDK 10.0.300 以降で利用できるという注記 | ドキュメントから削除 |
リバート対象となった元の更新は、CRL URLとOCSP URLを normal、detailed、diagnostic の各verbosityで表示すると説明する内容でした。しかし、その後のリバートPRでは「実装はリリース前に戻されていた」と説明されており、公開ドキュメントが実際のリリース挙動より先に進んでいた状態を修正したと読み取れます。(GitHub)
まず押さえるべき結論
今回のGitHub公式ドキュメント更新を見た管理者や開発者は、次のように判断すると実務上安全です。
| 判断ポイント | 推奨される見方 |
|---|---|
| GitHubのAPIやリポジトリ操作が変わったのか | いいえ。GitHub自体の仕様変更ではありません |
dotnet nuget verify の署名検証が不要になったのか | いいえ。署名検証の重要性は変わりません |
| CRL/OCSP URLが出力される前提で自動化してよいか | 現時点では避けるべきです |
| CI/CDで今すぐ止めるべき変更か | 多くの環境では緊急停止は不要です |
| 何を確認すべきか | SDKバージョン、実際の出力、ログ解析ルール、将来の .NET SDK 更新です |
特に重要なのは、公式ドキュメントの表だけを根拠にログパーサーや監査手順を作らないことです。dotnet nuget verify はCLIツールであり、出力形式はSDKバージョンやverbosityによって変わる可能性があります。自動化では「出力に特定の行があるか」よりも、コマンドの終了コード、検証結果、必要に応じた補助情報の抽出を分けて設計するべきです。
dotnet nuget verifyとは何を確認するコマンドか
dotnet nuget verify は、署名されたNuGetパッケージを検証する .NET CLI コマンドです。Microsoft Learnの現在の説明では、.NET 6 SDK 以降に適用され、署名付きNuGetパッケージを検証するコマンドとして案内されています。構文には --certificate-fingerprint、--verbosity、--configfile などのオプションがあります。(Microsoft Learn)
代表的な用途は次のとおりです。
- 社内で配布するNuGetパッケージの署名確認
- サードパーティパッケージの真正性確認
- CI/CDで生成した
.nupkgの検証 trustedSignersを使った署名者制御の確認- パッケージ復元やロックファイル検証エラーの調査
現在のMicrosoft Learnでは、--verbosity に quiet、minimal、normal、detailed、diagnostic を指定でき、既定値は minimal とされています。また、現行ページの表示項目一覧には、今回削除されたCRL URLとOCSP URLの行は含まれていません。(Microsoft Learn)
CRL URLとOCSP URLとは何か
CRLとOCSPは、証明書が失効していないかを確認するための仕組みです。
| 用語 | 意味 | NuGet署名検証での位置づけ |
|---|---|---|
| CRL | Certificate Revocation List。失効した証明書の一覧 | 証明書チェーン検証時に参照されることがある |
| OCSP | Online Certificate Status Protocol。証明書の失効状態をオンラインで確認する仕組み | 証明書が有効かどうかの確認に使われることがある |
| CRL/OCSP URL | 失効確認に使うエンドポイント | 監査、プロキシ、ファイアウォール設計で関心が高い |
企業環境では、NuGetの署名検証そのものよりも、「どの外部URLにアクセスする可能性があるのか」が問題になることがあります。閉域ネットワーク、プロキシ配下のGitHub Actionsランナー、Azure DevOpsのセルフホストエージェント、社内CAや証明書検証ポリシーを持つ環境では、CRL/OCSP URLの可視化が運用上の助けになります。
ただし、今回のリバート後は、少なくとも4月28日時点の公式ドキュメント上では dotnet nuget verify の出力表にCRL/OCSP URLは載っていません。したがって、これらのURLが必ず出力される前提で監査手順や許可リスト生成を組むのは危険です。
影響を受けやすいチームと受けにくいチーム
今回のGitHub公式ドキュメント更新は、全ユーザーに同じ影響があるわけではありません。次のように切り分けると、対応の優先度を判断しやすくなります。
| 対象 | 影響度 | 確認すべきこと |
|---|---|---|
| GitHubをコードホスティングとして使っているだけのチーム | 低 | GitHubの通常操作に影響はありません |
| .NETプロジェクトでNuGetを利用している開発者 | 中 | SDKバージョンとパッケージ署名検証の扱いを確認 |
dotnet nuget verify をCIで実行しているチーム | 高 | 出力解析、終了コード、verbosity指定を確認 |
| GitHub ActionsでNuGetパッケージをビルド・検証しているチーム | 高 | ランナーのSDKバージョン固定とログ保存方針を確認 |
| プロキシやファイアウォールを管理するクラウド管理者 | 中〜高 | CRL/OCSP URLをログから自動抽出していないか確認 |
| 監査証跡としてCLI出力を保存している組織 | 高 | 出力形式変更に依存しない証跡設計にする |
特に注意したいのは、dotnet nuget verify -v normal のログから証明書情報を正規表現で抜き出しているケースです。今回のようなドキュメント更新とリバートがあると、「出力されるはずの項目がない」「将来のSDKで項目が増える」といった両方向の変化が起こり得ます。
現場で確認すべきチェックリスト
今回の更新を受けて、開発者、クラウド管理者、アーキテクトが最初に確認すべき項目は次のとおりです。
SDKバージョンを固定しているか
CI/CDでは、ローカルPCとGitHub Actionsランナーで .NET SDK のバージョンが異なることがあります。SDKの違いは、CLIの出力や検証挙動の差につながります。
まずは次のコマンドで、実際に使っているSDKを確認します。
dotnet --infoGitHub Actionsでは、actions/setup-dotnet でSDKバージョンを明示しているか確認してください。明示していない場合、ランナーイメージの更新により、意図せず新しいSDKを使う可能性があります。
- name: Setup .NET SDK
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'.NET 10系やプレビューSDKを使っている場合は、より慎重に確認するべきです。出力変更が正式リリース前後で変わる可能性があるため、ドキュメント表だけでなく実コマンドのログを見て判断します。
dotnet nuget verify の実出力を保存して比較する
対象パッケージに対して、少なくとも minimal、normal、detailed の3段階で実行し、出力差分を保存します。
dotnet nuget verify ./artifacts/example.nupkg -v minimal | tee verify-minimal.log
dotnet nuget verify ./artifacts/example.nupkg -v normal | tee verify-normal.log
dotnet nuget verify ./artifacts/example.nupkg -v detailed | tee verify-detailed.logここで見るべき点は、CRL/OCSP URLが出るかどうかだけではありません。
- コマンドが成功しているか
- どの署名タイプが表示されるか
- 証明書のSubject、SHA256、Validity periodが出力されるか
- パッケージパスなど、ログに保存すべきでない情報が含まれていないか
- verbosityを上げたときにログ量が急増しないか
現在のMicrosoft Learnでは、normal 以上でパッケージパス、署名ハッシュアルゴリズム、証明書の発行者などが表示される表になっています。一方、CRL/OCSP URLの項目は現行表にはありません。(Microsoft Learn)
ログ解析を「固定行」ではなく「任意項目」にする
避けるべき実装は、次のようなパターンです。
dotnet nuget verify "$PKG" -v normal > verify.log
# CRL URLが必ずある前提のため危険
grep "CRL URL" verify.logより安全なのは、署名検証の成功判定と補助情報の抽出を分離する方法です。
set -euo pipefail
dotnet nuget verify "$PKG" -v normal | tee verify.log
# CRL/OCSP URLは、存在すれば記録する補助情報として扱う
grep -E "CRL URL|OCSP URL" verify.log || trueこの設計なら、現在のようにCRL/OCSP URLが出力されない環境でもジョブが不要に失敗しません。将来のSDKで出力が追加された場合も、ログに記録できます。
運用影響を見るときの判断基準
今回のドキュメント更新は小さな差分に見えますが、運用では次の3つに分けて考えると判断しやすくなります。
仕様変更ではなくドキュメント整合性の修正として見る
今回のコミットは、dotnet/docs の1ファイルに対する6行削除です。内容も dotnet-nuget-verify.md のverbosity表からCRL/OCSP URL関連の行を削除するものです。GitHubのリポジトリ機能、GitHub Actionsの仕様、GitHub APIの変更ではありません。(GitHub)
そのため、GitHub管理者がリポジトリ設定を急いで変更する必要は基本的にありません。見るべき対象は、GitHub上で動いている .NET/NuGet の自動化です。
署名検証の失敗と出力項目の有無を混同しない
CRL/OCSP URLがログに出ないからといって、署名検証が行われていないとは限りません。
Microsoft Learnでは、NuGetの署名付きパッケージ検証には、コード署名とタイムスタンプの両方に有効な証明書ルートストアが前提になると説明されています。また、dotnet nuget verify は署名されたNuGetパッケージを検証するコマンドです。(Microsoft Learn)
つまり、確認すべき順番は次のとおりです。
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 1 | コマンドの終了コード | 自動化の成功・失敗判定に最も重要 |
| 2 | 署名検証の結果 | パッケージの真正性確認に必要 |
| 3 | SDKとOS | 署名検証の前提が環境で異なる |
| 4 | verbosityごとの出力 | ログ解析や監査証跡に関係 |
| 5 | CRL/OCSP URLの有無 | ネットワーク調査や将来対応の補助情報 |
OSごとの署名検証の前提も確認する
NuGetの署名付きパッケージ検証は、OSによって既定の扱いやルートストアの利用方法が異なります。Microsoft Learnでは、Windowsでは復元時の検証が常に有効、Linuxでは .NET 8 SDK 以降で既定有効、macOSでは既定で無効と説明されています。(Microsoft Learn)
| OS | 実務での注意点 |
|---|---|
| Windows | 既定で検証が有効なため、CIのWindowsランナーでは証明書関連の失敗に注意 |
| Linux | .NET SDKのバージョンによって既定動作が変わるため、コンテナイメージ更新時に確認 |
| macOS | 署名検証の扱いに注意し、公式ドキュメントの推奨を確認してから有効化する |
GitHub Actionsでは、windows-latest、ubuntu-latest、macos-latest で結果が異なる可能性があります。マトリクスビルドをしている場合は、OS別に dotnet --info と dotnet nuget verify のログを比較すると原因調査が早くなります。
GitHub Actionsでの安全な確認手順
GitHub ActionsでNuGetパッケージの署名検証をしている場合は、次のような流れにすると、今回のような出力変更に強くなります。
| 手順 | 内容 | 目的 |
| -: | ——————————- | —————– |
| 1 | SDKバージョンを固定 | ランナー更新による出力差分を防ぐ |
| 2 | dotnet --info をログに残す | 後からSDK差分を追えるようにする |
| 3 | dotnet nuget verify は終了コードで判定 | 文字列依存の失敗を避ける |
| 4 | CRL/OCSP URLは任意項目として抽出 | 現在・将来どちらの出力にも対応 |
| 5 | ログを一定期間保存 | 監査や障害調査で比較可能にする |
例として、次のように書くと、CRL/OCSP URLの有無でジョブが失敗しにくくなります。
name: Verify NuGet package
on:
workflow_dispatch:
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET SDK
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
- name: Show .NET SDK info
run: dotnet --info
- name: Verify NuGet package signature
run: |
set -euo pipefail
dotnet nuget verify ./artifacts/*.nupkg -v normal | tee verify.log
grep -E "CRL URL|OCSP URL" verify.log || trueポイントは、grep の結果を成功条件にしないことです。CRL/OCSP URLが出力される環境では記録し、出力されない環境ではスキップします。これにより、今回のようなドキュメントリバート後でも、将来の出力追加後でも壊れにくいワークフローになります。
移行準備として今やるべきこと
今回の更新は「今すぐ移行が必要」というより、将来の .NET SDK 更新に備えて運用を固めるタイミングです。
2026年5月1日に作成された関連Issueでは、dotnet nuget verify が証明書に使われるCRL URLとOCSP URLを出力する変更が .NET 10.0.400 SDK に追加される予定として説明されています。また、推奨対応として、自動化で dotnet nuget verify の出力を解析している場合は、正規表現などを新しいフィールドに対応させる必要があるとされています。(GitHub)
つまり、4月28日のリバートだけを見て「CRL/OCSP URL出力はなくなった」と決め打ちするのも危険です。正しくは、次のように構えます。
| 時期 | 状態 | 対応 |
|---|---|---|
| 2026年4月28日時点 | ドキュメント上のCRL/OCSP URL説明がリバート | 現行ドキュメントに合わせて過剰な前提を外す |
| 2026年5月1日時点の関連Issue | .NET 10.0.400 SDKで追加予定の説明あり | 将来の出力追加に備えてログ解析を柔軟にする |
| 自社のSDK更新時 | 実際の出力が変わる可能性 | SDK更新前後でログ差分を比較する |
失敗しやすいポイント
今回のようなドキュメント更新では、次の勘違いが起きやすくなります。
| よくある誤解 | なぜ危険か | 正しい対応 |
|---|---|---|
| リバートされたので署名検証は不要 | 署名検証機能そのものの話ではありません | dotnet nuget verify の検証結果は引き続き確認 |
| CRL/OCSP URLが出ないのでネットワーク確認は不要 | 出力されないだけで、証明書検証時の通信要件が消えるとは限りません | プロキシ・証明書・ルートストアの実動作を確認 |
| ドキュメント表だけで自動化を作る | SDK更新で出力が変わると壊れます | 終了コード中心、出力項目は任意扱いにする |
| CRL URLは1つだけだと仮定する | 将来の例では同じ証明書に複数のCRL URLが出る可能性があります | 同一キーの複数値を扱える形式で保存 |
latest ランナー任せでよい | ランナーやSDKが更新されると出力差分が出ます | SDKバージョンを明示し、更新時に検証 |
特に、ログをJSON風のキー・バリューに変換している場合は注意が必要です。CRL URL のような同一キーが複数回出る可能性を考えると、単純な連想配列では最後の値だけが残ることがあります。将来対応を見据えるなら、同じキーを配列として保存できる設計にしておくと安全です。
技術判断者が見るべき運用上の論点
ソリューションアーキテクトや技術責任者は、今回の更新を単なるドキュメント差分ではなく、サプライチェーンセキュリティ運用の見直しポイントとして扱うと効果的です。
NuGetパッケージの検証をどこで実行するか
署名検証は、開発者のローカルPCだけでなく、CI/CDの中で実行するほうが再現性を確保しやすくなります。
おすすめは次のいずれかです。
| 実行場所 | 向いている用途 |
|---|---|
| パッケージ生成直後 | 自社パッケージの署名確認 |
| リリース前のCI/CD | 公開前の品質ゲート |
| 依存関係更新時 | 外部パッケージの確認 |
| 障害調査時 | 復元エラーや証明書エラーの切り分け |
ただし、毎回 diagnostic で大量ログを保存すると、ノイズが増えます。通常運用では normal または minimal を使い、問題調査時に detailed や diagnostic を使うのが現実的です。
SDK更新を変更管理に含める
.NET SDKの更新は、ビルド成功可否だけでなく、CLI出力やセキュリティ検証ログにも影響します。特にGitHub Actionsやコンテナビルドでは、次の項目を変更管理に含めるべきです。
- 使用する .NET SDK バージョン
- ベースイメージの更新日
dotnet nuget verifyのverbosity- ログ解析スクリプトのバージョン
- NuGet設定ファイルの場所
trustedSignersを使っているか- 署名検証失敗時のエスカレーション先
「ビルドできたから問題なし」ではなく、「検証ログの意味が変わっていないか」まで見ると、監査や障害対応で手戻りを減らせます。
次に取るべきアクション
今回のGitHub公式ドキュメント更新を受けて、まず実施すべきことは明確です。
1つ目は、GitHub ActionsやCI/CDで使っている .NET SDK のバージョンを確認することです。2つ目は、dotnet nuget verify の出力を実環境で取得し、CRL/OCSP URLの有無に依存した処理がないか確認することです。3つ目は、将来の .NET SDK 更新で出力項目が増えても壊れないように、ログ解析を柔軟にしておくことです。
今回のリバートは、GitHubの機能変更ではなく、リリース済みSDKの挙動と公式ドキュメントの整合性を取るための修正です。しかし、NuGet署名検証、証明書失効確認、CI/CDログ解析に関わるチームにとっては、見落とすと将来のSDK更新時にビルドや監査処理が壊れる可能性があります。
まずは自社のワークフローで次の3行を実行し、実際の状態を確認してください。
dotnet --info
dotnet nuget verify ./artifacts/*.nupkg -v normal
dotnet nuget verify ./artifacts/*.nupkg -v detailedそのうえで、CRL/OCSP URLを「必須の検証結果」ではなく「出力される場合がある補助情報」として扱う設計にしておけば、現在のリバートにも、将来の .NET SDK 変更にも対応しやすくなります。
コメント