`impostor-commit`: false positive on tag SHAs

[woodruffw]

Under the hood, a git tag has (at least?) two SHAs: one for the commit object corresponding to the tag, and another for the tag itself.

zizmor currently has a false positive on the latter: it knows about commit objects, but doesn't check the SHAs of tag objects themselves.

As a concrete example of this, github/codeql-action/upload-sarif@4e7d89f9f0a59fd9d68561cfbfd15475eaf75298 is a valid tag SHA, but zizmor flags it as an impostor commit:

{
    "node_id": "MDM6UmVmMjU5NDQ1ODc4OnJlZnMvdGFncy92Mw==",
    "object": {
        "sha": "4e7d89f9f0a59fd9d68561cfbfd15475eaf75298",
        "type": "tag",
        "url": "https://api.github.com/repos/github/codeql-action/git/tags/4e7d89f9f0a59fd9d68561cfbfd15475eaf75298"
    },
    "ref": "refs/tags/v3",
    "url": "https://api.github.com/repos/github/codeql-action/git/refs/tags/v3"
}

See also https://github.com/stacklok/frizbee/issues/206.

[woodruffw]

Working through one of these manually:

1. github/codeql-action/upload-sarif@4e7d89f9f0a59fd9d68561cfbfd15475eaf7529 is a false positive

2. 4e7d89f9f0a59fd9d68561cfbfd15475eaf7529 is an annotated tag object for tag v3, pointing at 396bb3e45325a47dd9ef434068033c6d5bb0d11a:

gh api /repos/github/codeql-action/git/tags/4e7d89f9f0a59fd9d68561cfbfd15475eaf75298

{
  "node_id": "TA_kwDOD3bUdtoAKDRlN2Q4OWY5ZjBhNTlmZDlkNjg1NjFjZmJmZDE1NDc1ZWFmNzUyOTg",
  "sha": "4e7d89f9f0a59fd9d68561cfbfd15475eaf75298",
  "url": "https://api.github.com/repos/github/codeql-action/git/tags/4e7d89f9f0a59fd9d68561cfbfd15475eaf75298",
  "tagger": {
    "name": "github-actions[bot]",
    "email": "41898282+github-actions[bot]@users.noreply.github.com",
    "date": "2024-11-12T19:22:08Z"
  },
  "object": {
    "sha": "396bb3e45325a47dd9ef434068033c6d5bb0d11a",
    "type": "commit",
    "url": "https://api.github.com/repos/github/codeql-action/git/commits/396bb3e45325a47dd9ef434068033c6d5bb0d11a"
  },
  "tag": "v3",
  "message": "v3\n",
  "verification": {
    "verified": false,
    "reason": "unsigned",
    "signature": null,
    "payload": null,
    "verified_at": null
  }
}

3. Accessing the tag directly via v3 doesn't provide any correlating info, and actually points to a new version of the v3 tag object (35d3f2d6f62ccd9c6d2a51979d4284031a600c09)?:

$ gh api /repos/github/codeql-action/git/refs/tags/v3
{
  "ref": "refs/tags/v3",
  "node_id": "MDM6UmVmMjU5NDQ1ODc4OnJlZnMvdGFncy92Mw==",
  "url": "https://api.github.com/repos/github/codeql-action/git/refs/tags/v3",
  "object": {
    "sha": "35d3f2d6f62ccd9c6d2a51979d4284031a600c09",
    "type": "tag",
    "url": "https://api.github.com/repos/github/codeql-action/git/tags/35d3f2d6f62ccd9c6d2a51979d4284031a600c09"
  }
}

gh api /repos/github/codeql-action/git/tags/35d3f2d6f62ccd9c6d2a51979d4284031a600c09
{
  "node_id": "TA_kwDOD3bUdtoAKDM1ZDNmMmQ2ZjYyY2NkOWM2ZDJhNTE5NzlkNDI4NDAzMWE2MDBjMDk",
  "sha": "35d3f2d6f62ccd9c6d2a51979d4284031a600c09",
  "url": "https://api.github.com/repos/github/codeql-action/git/tags/35d3f2d6f62ccd9c6d2a51979d4284031a600c09",
  "tagger": {
    "name": "github-actions[bot]",
    "email": "41898282+github-actions[bot]@users.noreply.github.com",
    "date": "2024-11-14T14:13:02Z"
  },
  "object": {
    "sha": "ea9e4e37992a54ee68a9622e985e60c8e8f12d9f",
    "type": "commit",
    "url": "https://api.github.com/repos/github/codeql-action/git/commits/ea9e4e37992a54ee68a9622e985e60c8e8f12d9f"
  },
  "tag": "v3",
  "message": "v3\n",
  "verification": {
    "verified": false,
    "reason": "unsigned",
    "signature": null,
    "payload": null,
    "verified_at": null
  }
}

4. Listing via gh api /repos/github/codeql-action/git/refs/tags shows the new tag object (excerpted):

  {
    "ref": "refs/tags/v3",
    "node_id": "MDM6UmVmMjU5NDQ1ODc4OnJlZnMvdGFncy92Mw==",
    "url": "https://api.github.com/repos/github/codeql-action/git/refs/tags/v3",
    "object": {
      "sha": "35d3f2d6f62ccd9c6d2a51979d4284031a600c09",
      "type": "tag",
      "url": "https://api.github.com/repos/github/codeql-action/git/tags/35d3f2d6f62ccd9c6d2a51979d4284031a600c09"
    }
  },

So, thinking about this more, I'm not sure it actually makes sense to handle this: the sha in this case was force-pushed over, meaning that its symbolic name now points to a completely different sha. The only reason we can query it at all is because force-pushes aren't deletions.