Closed5

npm package provenanceを公開しているパッケージで試してみた

けのびけのび

npmに公開しているパッケージにprovenance(発行元証明)を付与してみたので、その時のメモを残しておく。

GitHub Blogに「provenance」を付与するに至った背景や目的が書かれています。

https://github.blog/jp/2023-04-26-introducing-npm-package-provenance/

また、npm DocsにGitHub Actionsのワークフローでパッケージを公開する例が記されています。手助けになると思います。

https://docs.npmjs.com/generating-provenance-statements

けのびけのび

前置き

ソフトウェアを始めて起動するときに、「ソフトウェアの発行元が不明です。起動してもよろしいでしょうか?」という旨のメッセージを見たことはあるでしょうか。

あるアプリケーションを開発しているときに、サードパーティライブラリを用いることは常です。npm install コマンド等で利用するライブラリをプロジェクトに導入することは日常的にされています。コマンドを実行すると npm に公開・管理されているビルド成果物がプロジェクトの node_modules/ にダウンロードされます。

ダウンロードされた成果物は、いつ・どこで・どういう過程を経てビルドされたものなのかは分からないです。ただし、CI(GitHub Actions等)でリリースしている場合は分かりますが、その過程が公開されたビルド成果物と紐づいていないため断言はできないかもしれません。
もしかしたら、ローカル環境で悪意のあるコードでビルドした後に npm publish して、その後問題のあるコードは消してコミットするようなケースはないとも言えません。(そんなものがあるとは思いたくありませんが...)

いつ・どこで・どういう過程を経てビルドされたものが npm で公開されているのかを紐づけて、発行元に透明性を持たせるためのものが npm package provenance です。

ビルドと公開はCI/CDのワークフローで行う

CI/CDプロバイダーにて、パッケージをビルドしてして公開するというワークフローを構築する必要があります。現在ですとGitHub Actionsが選択できます。

ワークフローでビルドと公開まで行うことで、どのコミットでのビルドか、ビルドコマンドが可視化できます。(ジョブの構成ファイル、またはジョブのログなどが追える)

けのびけのび

GitHub Actionsでビルドと公開、発行元の署名

改めて、npmのGenerating provenance statementsにあるGitHub Actionsの例を見てみましょう。

ジョブにid-tokenのwrite権限を割り当てる

permissions:
  id-token: write

参考: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

provenance オプション

npm publish する際に --provenance オプションをつけることです。

npm publish --provenance

オプションをつける以外にも方法があります。https://docs.npmjs.com/generating-provenance-statements#using-third-party-package-publishing-tools が参考になります。

このとき、npm のアクセストークンが必要になります。

GitHubのリポジトリの設定から Actions secrets and variables にアクセスして、Secrets を追加します。Variables ではなく必ず Secrets としてください。Repository secretsかEnvironment secretsかは任意です。Environment別で変える場合はEnvironment secretsを選択しましょう。基本的にはRepository secretsで良いと思います。

以上が必要なWorkflowへの記述と設定です。

完成例

https://github.com/nemuvski/nacss/blob/v2.0.1/.github/workflows/latest-release.yml

けのびけのび

忘れてたのでメモ。

read and write access のアクセストークン必要。

Packages and scopes は適宜。公開するパッケージのものに限定するのがベター。Organizations も必要であればで良い。

アクセストークンの期限は短いものにしておく。

このスクラップは1ヶ月前にクローズされました