Default branch verification fails when reusable workflow repository has different branch

[lelia]

Problem Description

Although reusable workflows are now supported, when using the Scorecard Action I hit an edge case at the branch verification stage when the repository hosting the reusable workflow file has a different default branch (in our case, develop) than the repository calling the workflow (main).

Example showing workflow verification failure on the calling workflow: https://github.com/cisco-ospo/sample-project/actions/runs/7719025635/job/21041490540#step:4:1294

To test this, I temporarily swapped the default branch from develop to main on the reusable workflow host repository, then successfully reran the above workflow: https://github.com/cisco-ospo/sample-project/actions/runs/7719144312/job/21041843243#step:4:1293

Steps to Reproduce

1. Create repository with a default branch of dev or develop
2. Create a reusable workflow file for the Scorecard Action
3. Create repository with a default branch name of main
4. Create a workflow file which calls the reusable workflow from Step 2
5. Run the Scorecard workflow with publish_results set to true

Let me know if any other details would be of use!

[spencerschrock]

Haven't dug into it too much, but I think the fix from #295 didn't take advantage of new fulcio fields. I think this could be resolved based on the fields we check. https://github.com/ossf/scorecard-webapp/blob/f1b48c0346aaaaf8edb18c77797e5c71daa87ce3/app/server/post_results.go#L508-L528

Currently we grab (quotes from this doc):

• 1.3.6.1.4.1.57264.1.3 | GitHub Workflow SHA (deprecated)
  • This contains the sha claim from the GitHub OIDC Identity token that contains the commit SHA that the workflow run was based upon
• 1.3.6.1.4.1.57264.1.5 | GitHub Workflow Repository (deprecated)
  • This contains the repository claim from the GitHub OIDC Identity token that contains the repository that the workflow run was based upon
• 1.3.6.1.4.1.57264.1.6 | GitHub Workflow Ref (deprecated)
  • This contains the ref claim from the GitHub OIDC Identity token that contains the git ref that the workflow run was based upon

Whereas there are some newer fields that will hopefully give us the details we need to distinguish between the default branch of the calling repo, and not care about the branch of the re-usable workflow repo.

I seem to remember these fields distinguish between the source (repo which calls the re-usable workflow) and the build signer (repo the reusable workflow is in). But someone would need to double check I didn't flip those definitions:

• 1.3.6.1.4.1.57264.1.9 | Build Signer URI
• 1.3.6.1.4.1.57264.1.10 | Build Signer Digest
• 1.3.6.1.4.1.57264.1.12 | Source Repository URI
• 1.3.6.1.4.1.57264.1.13 | Source Repository Digest
• 1.3.6.1.4.1.57264.1.14 | Source Repository Ref
  • Source Repository Ref that the build run was based upon. For example: refs/head/main git branch or tag