npm trusted publishing設定の期限切れ：48時間以内の初回公開、issue_commentトークンの拒否

48時間が適用される範囲

新しく作った設定は未検証の状態で、この時点から48時間が進む。この設定で初回の公開に成功すると検証済みになり、期限切れの規則から外れる。

その前に48時間が過ぎると、もう公開を承認できない。期限切れの項目はtrusted publisherの設定に表示され続けるが、パッケージごとの上限には数えられない。

新たな48時間を得るには設定を作り直す必要があり、通常の編集では期限はやり直しにならない。リポジトリやプロジェクトの識別情報を変えると新しい信頼関係が必要になり、同じパッケージの他の有効な設定には影響しない。

公開が拒否されるGitHub Actionsのイベント

同じ発表には、GitHub Actionsのイベントに関する制限も含まれている。npmは既存のpull_request_targetの制限に加え、issue_commentイベントで発行されたtrusted publishingトークンも拒否する。

影響を受ける場合は、push、release、workflow_dispatchのような許可されたイベントに公開を移すよう案内している。

設定文書が求める実行条件

npmの文書はnpm CLI 11.5.1以上とNode.js 22.14.0以上を求めている。対応環境はGitHubホストのActionsランナー、GitLab.comの共有ランナー、CircleCIクラウドで、セルフホストランナーにはまだ対応していない。

1つのパッケージに設定できるtrusted publisherは最大10個だ。GitHub Actionsでは組織またはユーザー、リポジトリ、ワークフローのファイル名、任意の環境名を正確に一致させる必要があり、ワークフローにはid-token: write権限が必要だ。

npm stage publishは常に許可され、npm publishで直接公開する権限は別に選ぶ。npmは設定の保存時に内容を検証しないため、誤りは実際の公開時に表に出る。

初回リリースの日程に合わせた設定手順

リリースワークフローのトリガー、ランナー、公開権限を先に準備し、予定した初回リリースの直前に信頼関係を作る順序が期限とよく合う。設定を生かすためにレビューを急ぐ必要もない。

すでに期限切れなら、リリースの準備ができてから作り直し、意図したtrusted publishingの経路で公開が成功するかを確かめる。許可されたイベントを使う場合でも、レビューとリリースの管理は引き続き必要だ。

注意点：既存のトークン経路と文書の変更

48時間の期限は、検証されていないtrusted publisherの設定にだけ適用される。パッケージの設定が許す限り、従来のトークン認証は別の公開経路として残る。

10月6日の確認時点ではnpmの設定文書に期限切れの規則はなかったが、10月14日に再確認した文書には、2日以内に初回の公開を終える必要があるという節が追加されていた。文書は、期限切れの設定を削除して新しく作るよう案内している。

変更履歴は、発表前に作られたがまだ検証されていない設定をどう扱うかを明らかにしていない。そうした設定の実際の状態は、変更履歴だけでは分からない。

npmのtrusted publisherは、もう前もって作っておく設定ではなく、初回リリースの直前に作って48時間以内に検証する設定だ。