Skip to content

Natively support automation around inspection of an artifact's attestations #9245

Description

@williammartin

Describe the feature or problem you’d like to solve

Given an artifact, I want to inspect the related sigstore bundle in an automated, GitHub CLI-native manner

Currently, the hidden command attestation inspect allows inspection of a sigstore bundle. To invoke this command, you provide the path of an artifact and the path to a bundle e.g.

gh attestation inspect gh_2.50.0_macOS_amd64.zip --bundle sha256:d18acd3874c9b914e0631c308f8e2609bd45456272bacfa70221c46c76c635f6.jsonl

This means that a bundle has to be downloaded first through some means, most likely gh attestation download. However, these commands aren't easily composable because attestation download works like this:

➜  gh attestation download ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli
Wrote attestations to file sha256:5d5ee16345251a652495e4be8f190ec00209298f71e3666a80d9394cd0117ceb.jsonl.
Any previous content has been overwritten

The trusted metadata is now available at sha256:5d5ee16345251a652495e4be8f190ec00209298f71e3666a80d9394cd0117ceb.jsonl

As a human I then need to read this and copy it, or write some horrible script in order to parse the path and provide it to the --bundle flag of attestation inspect.

Proposed solution

I can think of a few approaches to solve this problem.

Print file path in non-TTY output

The simplest approach here seems to be to adjust the non-TTY output to work like so:

➜  gh attestation download ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli
sha256:5d5ee16345251a652495e4be8f190ec00209298f71e3666a80d9394cd0117ceb.jsonl

Which could then be used like so:

➜ gh attestation inspect ~/Downloads/gh_2.51.0_macOS_amd64.zip --bundle $(gh attestation download ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli)

Print to stdout by default, and accept stdin

A more composable solution would be to not write a file by default but instead print the bundle to stdout, and then adjust download to accept the bundle on stdin like so:

➜ gh attestation download ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli | gh attestation inspect ~/Downloads/gh_2.51.0_macOS_amd64.zip --bundle -

The - is a commonly accepted way of saying "use stdin instead of a file"

With this choice, we could support a --output flag, but I'm not really sure that's necessary when we could use standard terminal redirection to write the output to a file e.g. gh attestation download ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli > attestation.json. If we wanted to enforce the existing filename structure then we could support --output-dir. In this case we would also want to adjust the non-TTY stdout to print the file path.

Avoid needing to download the attestations altogether

Instead of requiring a downloaded bundle, we could accept the same flags as verify and download and have inspect grab the bundle e.g.

gh attestation inspect ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli

Activity

  1. steiza commented on Jun 24, 2024

    @steiza
    Contributor

    On the one hand, it is a little weird that gh attestation download only saves to a file, and doesn't support stdout like most *nix commands do.

    On the other hand, taking a step back and asking "what problem are we trying to solve?" a command like the proposed:

    gh attestation inspect ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli

    Looks a lot like the existing:

    gh attestation verify ~/Downloads/gh_2.51.0_macOS_amd64.zip --repo cli/cli

    Maybe if you have't already downloaded the bundle, you should just use gh attestation verify directly? I might be misunderstanding the use-case!

  2. williammartin commented on Jun 24, 2024

    @williammartin
    MemberAuthor

    Maybe if you have't already downloaded the bundle, you should just use gh attestation verify directly? I might be misunderstanding the use-case!

    Well, attestation verify also accepts --bundle so the intention seems orthogonal. One exists to:

    Verify the integrity and provenance of an artifact using its associated cryptographically signed attestations.

    And the other exists to:

    Inspect a downloaded Sigstore bundle for a given artifact.

    It seems like the purpose of the latter is to give more information about the attestations beyond "this is legit".

    Paging @phillmv @malancas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementa request to improve CLIgh-attestationrelated to the gh attestation command

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions