Initial implement

[Xynnn007]

The initial implement includes work

1. basic framework for verifying & pulling artifacts from kata-repo, calculation reference values scripts
2. CI pipeline
3. README.md

A test release https://github.com/Xynnn007/reference-values/releases/tag/test-v0.1.6

[Copilot]

Pull request overview

Adds the initial end-to-end framework for producing and publishing CoCo release reference values from upstream Kata artifacts, including provenance verification and a GitHub Actions pipeline.

Changes:

• Introduces versions.yaml as the declarative release/artifact configuration and adds scripts to verify upstream attestations and compute reference values.
• Adds a GitHub Actions workflow to verify attestations, build reference-values.json, and (on release/workflow_call) publish and attest the output.
• Adds initial documentation (README.md) and basic repository hygiene (.gitignore).

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
versions.yaml	Defines Kata source metadata and pinned artifact digests/calculators used to compute reference values.
verify-provenance.sh	Verifies GitHub attestation claims for OCI artifacts (digest/workflow/ref checks).
verify-attestations.py	Iterates configured artifacts and runs provenance verification for each.
release.py	Pulls OCI artifacts, extracts payloads, downloads calculators, executes them, and writes output JSON.
update-oras-digests.py	Utility to resolve and update artifact digests for a given Kata tag/arch.
README.md	Documents repository purpose, local usage, workflow behavior, and verification guidance.
.gitignore	Ignores Python cache and generated results/.
.github/workflows/reference-values.yml	CI workflow to verify attestations, build reference values, and attest/publish on release.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

[amd-aliem]

I think snp combines these artifacts into one measurement - would it be possible/make sense to change the oras_sha256 into a named list? (Where tdx can just list one element):

For tdx kernel:

      sources:
        - oci_name: kernel
          oras_sha256: <sha>

For sev:

      sources:
        - oci_name: ovmf-sev
          oras_sha256: <sha>
        - oci_name: kernel
          oras_sha256: <sha>

or if we share kernel we can define at top and list a reference to it.

[amd-aliem]

I think this combined snp measurement also includes kernel params, which includes dm-verity hash... so not sure how that'd work logistically yet since we have to fetch that from kata or re-compute with the image at some point? (No request here, just thinking aloud about how this would work for SNP)

cc @hgowda-amd

[Xynnn007]

Hi @amd-aliem @hgowda-amd I have updated the code based on your comments, mainly

1. Convert from artifact level to reference value level
2. Use separate yaml files for different archs, which will help maintaince.

[mkulke]

maybe it's just me, but this calculator_url/sha/runtime block in the yaml feels a overly abstract to me and it's conflating 2 things:

Could the calculation logic be inlined in a script instead?

I think a version.yaml still makes sense, but for the tools that we need to calculate the measurements:

git:
  td-shim:
    url: https://github.com/confidential-containers/td-shim
    digest: 123abc...

the script/software that assembles reference-values by calling those tools is the business logic of this repository. I don't think we need to generalize this part. The measurement logic itself is part of the provenance attestation in the repo.

[Xynnn007]

So your idea is to just reference the repo sha and the path of the tool under the repo? Originally I thought that the repo would sometimes be big and with git ref we can just download one file.

I did not get the point about the other thing of "conflating 2 things".

Do you mean by script-able tool? If so, I would like to make such an assumption—or perhaps a convention—whereby the scripted/call-able reference value calculation tool simultaneously outputs the hexadecimal representation of the reference values ​​to stdout. This would greatly facilitate the generation of reference value manifests.

I previously considered requiring that all these scripts/tools be housed within this repository; however, given that hardware vendors and similar entities tend to prefer maintaining their associated toolsets in their own repositories, I finally decided against doing so.

[mkulke]

So your idea is to just reference the repo sha and the path of the tool under the repo? Originally I thought that the repo would sometimes be big and with git ref we can just download one file.

that's fine, but we don't have to encode this in versions.yml

I did not get the point about the other thing of "conflating 2 things".

1. versions.yaml as a dictionary for reproducible tools
2. (shell) instructions to produce the measurements

Do you mean by script-able tool? If so, I would like to make such an assumption—or perhaps a convention—whereby the scripted/call-able reference value calculation tool simultaneously outputs the hexadecimal representation of the reference values ​​to stdout. This would greatly facilitate the generation of reference value manifests.

Ah no, not a script-able tool. Simple a tool that generates measurements for CoCo, in a Makefile, python, bash, golang or whatever, e.g:

make reference-values.json COCO_RELEASE=0.20.1

or

./generate-measurements.sh --release 0.20.1

Instead of putting the instructions in versions.yaml.

I previously considered requiring that all these scripts/tools be housed within this repository; however, given that hardware vendors and similar entities tend to prefer maintaining their associated toolsets in their own repositories, I finally decided against doing so.

that's fine, we can download individual files in the measurement script/makefile/tool, but we can just keep repo + digest in versions.yaml.

[mkulke]

or briefly:

config-loader.py looks a like a miniature github-actions execution engine and versions.yaml like a workflow.yaml. "config-loader.py" can just be "generate-measurements.py" IMO.

[Xynnn007]

I have refactored the repo a lot. Now

• versions.yaml defines kata version, tools to be used, archs
• arch/*.yaml defines the script name to calculate reference value, and the inputs

PTAL if this is the expected shape?

[mkulke]

IMO this is still too much code/accidential complexity for the purpose of this repo (we have python scripts that are calling bash scripts that are calling github cli tools, measurement plugins, loggers, etc), but I might be mistaken about the purpose and scope.

What I think a user wants from this repo:

1 oci image artifact (ghcr.io/confidential-containers/reference-values:0.21.0) that contains reference-values.json + 1 associated cosign attestation, also as oci image, so a user can verify the provenance of the artifact.

The gh cli is already a convenience tool for verifying provenance claims, there are others. I think it's sufficient if we show how to verify the repo's artifact with the gh cli in the README (built on main, in this repo, on a github-runner, etc).

Producing the reference-values.json artifact should be also somewhat trivial. AFAIU we don't need flexibility, we do know the inputs and if something doesn't look exactly like how we expect it to be, this is suspicious and we should bail out.

• Download + verfiy artifacts from Kata
• Clone the tools td-shim, sev-snp-measure, etc (assuming the tools don't come as attested artifacts via trusted-publishing or something else)
• Build the tools (if necessary)
• Run tool X on artifact Y (static matrix, no flexibility required)
• Write results to reference-values.json (static schema, every key is known, no flexibility required)

(for peerpod tpm ref values, they are calculated in-repo, so you would only download+verify those ref-values)

this would all fill neatly in brief script or Makefile, IMO.

If I am mistaken and we do indeed need all this machinery. then maybe we can still consolidate. e.g. use python for everything instead of forking out to shell scripts and tools.

[mkulke]

Can we describe how?

[Xynnn007]

I removed the line 5. And only a simple introduction for the repo. Then How It Works section will tell how

[Xynnn007]

@mkulke I want to make it simpler, too.

• Download + verfiy artifacts from Kata
• Clone the tools td-shim, sev-snp-measure, etc (assuming the tools don't come as attested artifacts via trusted-publishing or something else)
• Build the tools (if necessary)
• Run tool X on artifact Y (static matrix, no flexibility required)
• Write results to reference-values.json (static schema, every key is known, no flexibility required)

This is exactly the target in my mind for the repo. I want to make it plugin-able framework - for archs and reference value items. Thus I want to make a "static part" the works like a black box, and get inputs, e.g. kata version, artifact names; reference value id / tool / how to run the tool

so, version things can be put inside a yaml. How to run the tool can be put into a script. Then we need the blackbox to read the yaml, drive the whole process, collect results. This is what the python scripts do now.

I'd like to hear about your concrete inspiring ideas - as always!

[mkulke]

This is exactly the target in my mind for the repo. I want to make it plugin-able framework - for archs and reference value items. Thus I want to make a "static part" the works like a black box, and get inputs, e.g. kata version, artifact names; reference value id / tool / how to run the tool

yeah, I guess I'm stumbling over the "plugin-able framework" aspect. I don't see why this is required. But this is personal preference to some degree, so let's see what others say.