docker / docker/github-builder

Question on verification target

オープン
#153 コメント 0 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
言語のデータがありません
スター
83
フォーク
23
平均マージ
2日 22時間
マージ済み PR(30日)
8

説明

Hi, and thanks a lot for this useful action 🙂 .

I was experimenting a bit with it and I have a question. From an end-user perspective, i.e., someone who is about to pull an image and use it locally, what's the recommended flow to verify it? I see there's an independent workflow for verifying images (docker/github-builder/.github/workflows/verify.yml@v1), but I'd like some help to understand what is it verifying, and how one can simulate it locally.

For example, I've built ghcr.io/apyrgio/dangerzone-test-github-builder@sha256:8eb497e92ed7071fc925e306214a6368bb2a3c90939ce15123d09471d3ba5a66 using this workflow.

Looking at the build job of this workflow, in the "Set result output" step, I see the following build output:

{
  "verifyCommands": "cosign verify --experimental-oci11 --new-bundle-format --certificate-oidc-issuer https://token.actions.githubusercontent.com/ --certificate-identity-regexp ^https://github.com/docker/github-builder/.github/workflows/build.yml.*$ ghcr.io/apyrgio/dangerzone-test-github-builder@sha256:c40cc89132c63ef82310cf1a2c05a6ad656ec88b9a9d29246825b470f1354a57",
  "imageDigest": "sha256:8eb497e92ed7071fc925e306214a6368bb2a3c90939ce15123d09471d3ba5a66",
  "artifactName": "",
  "signed": true
}

It seems that the verifyCommands field includes the commands that a user can run locally to verify the container image. What I'm not sure about is what we are verifying here.

In this case, the cosign verify command verifies the sha256:c40cc89132c63ef82310cf1a2c05a6ad656ec88b9a9d29246825b470f1354a57 manifest, which includes an in-toto attestation for the sha256:37ca0e50004ab4b4a51e6f87e6d9528a7d000e0a3702ff0a3c59181f7a558443 manifest, which is basically the image data for the linux/amd64 platform.

But the user will not pull this digest. They will instead pull either the root one, the platform specific one, or the image tag. For all the above, if they to run cosign verify ... against them, they will get the following:

Error: no signatures found
error during command execution: no signatures found

Should there be signatures for these digests?

Finally, the provided cosign verify ... command ensures that the image was created by this GitHub action. What's much more interesting though is the other attestation attributes, such as the repository or the source commit hash. If a user wants to verify against those, should they use the cosign verify ... command, or switch to cosign verify-attestation ... and pass a CUE policy or similar?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

docker/github-builder/.github/workflows/verify.yml@v1 と、.github/workflows/github-build.yml の build ジョブにある「Set result output」ステップから始めます。出力される verifyCommands と、イメージ、プラットフォーム、attestation の digest を追跡し、推奨されるローカル検証フローと、ユーザーが repository または source-commit の属性を検証する方法を文書化します。digest の動作と、cosign の検証コマンドのどちらを選ぶかが明確に説明されていれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
docker, github-actions
領域
devops, security
issue の種類
ドキュメント
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
38/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。