`frizbee actions` generates wrong/invalid commit ref? #206

woodruffw · 2024-10-31T19:13:50Z

Describe the issue

Hi there! Thanks for frizbee, it's an awesome tool.

@chenrui333 ran frizbee on zizmor here: woodruffw/zizmor#90 and it produced a strange (seemingly nonexistent) pinned commit ref.

In particular, this:

      - name: Install the latest version of uv
        uses: astral-sh/setup-uv@v3

became this:

      - name: Install the latest version of uv
        uses: astral-sh/setup-uv@c5df01c9e4233fcd789bd004850aa36809d07727 # v3

However, that commit (c5df01c9e4233fcd789bd004850aa36809d07727) doesn't appear to exist at all, either on the upstream or anywhere in the fork network: astral-sh/setup-uv@c5df01c

I think the correct ref here should be 3b9817b1bf26186f03ab8277bab9b827ea5cc254, corresponding to tags v3 and v3.2.0: https://github.com/astral-sh/setup-uv/releases/tag/v3.2.0

To Reproduce

To reproduce, run frizbee actions .github/workflows on https://github.com/woodruffw/zizmor and observe the ref 🙂

frizbee version output:

Version: 0.1.4
Go Version: go1.23.2
Git Commit: 
Commit Date: 
OS/Arch: darwin/arm64
Dirty: false

What version are you using?

v0.1.4

The text was updated successfully, but these errors were encountered:

woodruffw · 2024-10-31T19:16:00Z

Minimal reproducer:

$ frizbee actions astral-sh/setup-uv@v3
astral-sh/setup-uv@c5df01c9e4233fcd789bd004850aa36809d07727

woodruffw · 2024-10-31T19:49:12Z

GitHub's own API endpoints appear to be returning the wrong ref here:

http GET https://api.github.com/repos/astral-sh/setup-uv/git/refs/tags/v3

yields:

{
    "node_id": "REF_kwDOMnghHqxyZWZzL3RhZ3MvdjM",
    "object": {
        "sha": "c5df01c9e4233fcd789bd004850aa36809d07727",
        "type": "tag",
        "url": "https://api.github.com/repos/astral-sh/setup-uv/git/tags/c5df01c9e4233fcd789bd004850aa36809d07727"
    },
    "ref": "refs/tags/v3",
    "url": "https://api.github.com/repos/astral-sh/setup-uv/git/refs/tags/v3"
}

...and object.url points to the real commit ref seemingly:

http GET https://api.github.com/repos/astral-sh/setup-uv/git/tags/c5df01c9e4233fcd789bd004850aa36809d07727

yields:

{
  "node_id": "TA_kwDOMnghHtoAKGM1ZGYwMWM5ZTQyMzNmY2Q3ODliZDAwNDg1MGFhMzY4MDlkMDc3Mjc",
  "sha": "c5df01c9e4233fcd789bd004850aa36809d07727",
  "url": "https://api.github.com/repos/astral-sh/setup-uv/git/tags/c5df01c9e4233fcd789bd004850aa36809d07727",
  "tagger": {
    "name": "eifinger",
    "email": "eifinger@users.noreply.github.com",
    "date": "2024-10-25T12:13:43Z"
  },
  "object": {
    "sha": "3b9817b1bf26186f03ab8277bab9b827ea5cc254",
    "type": "commit",
    "url": "https://api.github.com/repos/astral-sh/setup-uv/git/commits/3b9817b1bf26186f03ab8277bab9b827ea5cc254"
  },
  "tag": "v3",
  "message": "Release v3.2.0\n",
  "verification": {
    "verified": false,
    "reason": "unsigned",
    "signature": null,
    "payload": null
  }
}

chenrui333 · 2024-10-31T20:13:24Z

another idea is probably we just query /tags endpoint

$ gh api /repos/astral-sh/setup-uv/tags | jq -r '.[] | select(.name == "v3") | .commit.sha'
3b9817b1bf26186f03ab8277bab9b827ea5cc254

blkt · 2024-11-04T22:11:38Z

Hi @woodruffw, thank you for the thorough investigation and the reproducer, this is awesome!
Thank you @chenrui333 as well for the proposed solution!

I'll try to have a better look later this week, possibly early next week.

Hacks around stacklok/frizbee#206. Signed-off-by: William Woodruff <william@trailofbits.com>

blkt · 2024-11-15T20:15:33Z

@woodruffw it looks like there are two steps involved

first obtain the tag's identifier using its name

$ gh api /repos/astral-sh/setup-uv/git/refs/tags/v3
{
  "ref": "refs/tags/v3",
  "node_id": "REF_kwDOMnghHqxyZWZzL3RhZ3MvdjM",
  "url": "https://api.github.com/repos/astral-sh/setup-uv/git/refs/tags/v3",
  "object": {
    "sha": "57b15becf94238836cd31b932339e7d72a15ef9c",
    "type": "tag",
    "url": "https://api.github.com/repos/astral-sh/setup-uv/git/tags/57b15becf94238836cd31b932339e7d72a15>
  }
}

then use object.sha to get the details of the tag

$ gh api /repos/astral-sh/setup-uv/git/tags/57b15becf94238836cd31b932339e7d72a15ef9c
{
  "node_id": "TA_kwDOMnghHtoAKDU3YjE1YmVjZjk0MjM4ODM2Y2QzMWI5MzIzMzllN2Q3MmExNWVmOWM",
  "sha": "57b15becf94238836cd31b932339e7d72a15ef9c",
  "url": "https://api.github.com/repos/astral-sh/setup-uv/git/tags/57b15becf94238836cd31b932339e7d72a15ef>
  "tagger": {
    "name": "eifinger",
    "email": "eifinger@users.noreply.github.com",
    "date": "2024-11-15T08:23:29Z"
  },
  "object": {
    **"sha": "e779db74266a80753577425b0f4ee823649f251d",**
    "type": "commit",
    "url": "https://api.github.com/repos/astral-sh/setup-uv/git/commits/e779db74266a80753577425b0f4ee8236>
  },
  "tag": "v3",
  "message": "Release v3.2.3\n",
  "verification": {
    "verified": false,
    "reason": "unsigned",
    "signature": null,
    "payload": null,
    "verified_at": null
  }
}

finally, get object.sha again to get the actual commit (type equals commit).

I will open a PR shortly, but I'd love to hear opinions from @jhrozek and @JAORMX, plus some better testing before we can merge it.

The command `frizbee actions <action>@<tag>` incorrectly retrieves the tag's ref rather than the commit's one. The tag's ref should instead be used to retrieve the details of the tag, which contain the ref of the commit. This change changes `getCheckSumForTag` to lookup the right field using two subsequent call to GitHub. Fixes #206

woodruffw · 2024-11-15T20:48:33Z

Thanks @blkt! Those steps looks right to me, and I greatly appreciate your response!

JAORMX · 2024-11-15T20:56:22Z

I'm still not quite sure why we're getting this unexistent ref to begin with. Have we dug into that?

woodruffw · 2024-11-15T21:04:09Z

I'm still not quite sure why we're getting this unexistent ref to begin with. Have we dug into that?

The ref does exist: it's just a tag ref, not a commit ref. This ends up working since GitHub knows how to handle both, but GitHub generally only shows commit refs in the UI itself (including on the tags/releases pages).

TL;DR both refs are correct, but the commit ref is the "canonical" one as far as GitHub is concerned.

JAORMX · 2024-11-15T21:12:18Z

Ah! That makes sense. And I see @blkt even has a patch in the works

The command `frizbee actions <action>@<tag>` incorrectly retrieves the tag's ref rather than the commit's one. The tag's ref should instead be used to retrieve the details of the tag, which contain the ref of the commit. This change changes `getCheckSumForTag` to lookup the right field using two subsequent call to GitHub. Fixes #206

blkt · 2024-11-15T21:51:05Z

The main difference is that "partial" tags (e.g. v3 when you have v3.6.0) resolve to a tag object, while "full" tags (e.g. the v3.6.0) resolve to commits objects directly, so it worked depending on the exact tagging mechanism.

The command `frizbee actions <action>@<tag>` incorrectly retrieves the tag's ref rather than the commit's one. The tag's ref should instead be used to retrieve the details of the tag, which contain the ref of the commit. This change changes `getCheckSumForTag` to lookup the right field using two subsequent call to GitHub. Fixes #206

woodruffw · 2024-11-16T00:51:33Z

The main difference is that "partial" tags (e.g. v3 when you have v3.6.0) resolve to a tag object, while "full" tags (e.g. the v3.6.0) resolve to commits objects directly, so it worked depending on the exact tagging mechanism.

I could be wrong, but I think the reason underneath this is convention: the "partial" tags could resolve to commit objects if they were re-tagged using the commit instead of the "full" tag, but in practice GitHub's official actions (and many others) seem to do the former.

(The interactions here are very confusing: I think the behavior also varies if the tag is a "plain" tag versus an "annotated" one.)

See stacklok/frizbee#206 Signed-off-by: William Woodruff <william@trailofbits.com>

See stacklok/frizbee#206. Signed-off-by: William Woodruff <william@yossarian.net>

woodruffw · 2024-12-16T22:49:16Z

@JAORMX Thanks for the fix here! Would it be possible to get this landed in a release? Right now brew et al. are carrying patches for this, which is not ideal.

* ci: harden workflows This hash-pins all of our workflows and fixes some (low-impact) zizmor findings. It also adds a `zizmor` workflow that'll run on pushes and PRs to prevent issues from sneaking in. Signed-off-by: William Woodruff <william@yossarian.net> * ci: zizmor: fix hash pin See stacklok/frizbee#206. Signed-off-by: William Woodruff <william@yossarian.net> --------- Signed-off-by: William Woodruff <william@yossarian.net>

JAORMX · 2024-12-20T08:02:19Z

@woodruffw done did https://github.com/stacklok/frizbee/releases/tag/v0.1.5

woodruffw · 2024-12-20T09:19:14Z

Thank you!

woodruffw added the bug Something isn't working label Oct 31, 2024

woodruffw mentioned this issue Oct 31, 2024

ci: pin workflow action sha woodruffw/zizmor#90

Merged

blkt self-assigned this Nov 4, 2024

woodruffw added a commit to trailofbits/sigstore-rekor-types that referenced this issue Nov 13, 2024

fix commits

844c47f

Hacks around stacklok/frizbee#206. Signed-off-by: William Woodruff <william@trailofbits.com>

woodruffw mentioned this issue Nov 13, 2024

impostor-commit: false positive on tag SHAs woodruffw/zizmor#151

Closed

blkt mentioned this issue Nov 15, 2024

Resolve commit ref correctly. #212

Merged

blkt closed this as completed in #212 Nov 18, 2024

blkt closed this as completed in fbef552 Nov 18, 2024

woodruffw added a commit to trailofbits/rfc3161-client that referenced this issue Nov 18, 2024

fix setup-uv hashes

35e8020

See stacklok/frizbee#206 Signed-off-by: William Woodruff <william@trailofbits.com>

This was referenced Nov 23, 2024

feat: pin workflow action sha Homebrew/.github#212

Closed

feat: pin workflow action sha Homebrew/.github#213

Merged

This was referenced Dec 14, 2024

gopeed 1.6.4 (new formula) Homebrew/homebrew-core#201080

Merged

frizbee: add build patch to resolve commit correctly Homebrew/homebrew-core#201116

Merged

woodruffw added a commit to psf/cachecontrol that referenced this issue Dec 16, 2024

ci: zizmor: fix hash pin

6b1f6fa

See stacklok/frizbee#206. Signed-off-by: William Woodruff <william@yossarian.net>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`frizbee actions` generates wrong/invalid commit ref? #206

`frizbee actions` generates wrong/invalid commit ref? #206

woodruffw commented Oct 31, 2024

woodruffw commented Oct 31, 2024

woodruffw commented Oct 31, 2024

chenrui333 commented Oct 31, 2024

blkt commented Nov 4, 2024

blkt commented Nov 15, 2024

woodruffw commented Nov 15, 2024

JAORMX commented Nov 15, 2024

woodruffw commented Nov 15, 2024

JAORMX commented Nov 15, 2024

blkt commented Nov 15, 2024

woodruffw commented Nov 16, 2024

woodruffw commented Dec 16, 2024

JAORMX commented Dec 20, 2024

woodruffw commented Dec 20, 2024

frizbee actions generates wrong/invalid commit ref? #206

frizbee actions generates wrong/invalid commit ref? #206

Comments

woodruffw commented Oct 31, 2024

Describe the issue

To Reproduce

What version are you using?

woodruffw commented Oct 31, 2024

woodruffw commented Oct 31, 2024

chenrui333 commented Oct 31, 2024

blkt commented Nov 4, 2024

blkt commented Nov 15, 2024

woodruffw commented Nov 15, 2024

JAORMX commented Nov 15, 2024

woodruffw commented Nov 15, 2024

JAORMX commented Nov 15, 2024

blkt commented Nov 15, 2024

woodruffw commented Nov 16, 2024

woodruffw commented Dec 16, 2024

JAORMX commented Dec 20, 2024

woodruffw commented Dec 20, 2024

`frizbee actions` generates wrong/invalid commit ref? #206

`frizbee actions` generates wrong/invalid commit ref? #206