🌱 feat: release homebrew formulae

[developer-guy]

Signed-off-by: Batuhan Apaydın [email protected]

Fixes #1364

• Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• PR title follows the guidelines defined in https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

feature

• What is the current behavior? (You can also link to an open issue here)

There is no active support

• What is the new behavior (if this is a feature change)?

create HomeBrew formula for scorecard

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No, it doesn't introduce any breaking change.

Users now can be able to install scorecard via brew.

• Other information:

[github-actions]

Integration tests success for
[0f87dc7]
(https://github.com/ossf/scorecard/actions/runs/1551219722)

[naveensrinivasan]

How will this action have permission to write to another repository?

[developer-guy]

This token should have enough permissions to do that, right, if not, it'll fail.

[naveensrinivasan]

OK. Thanks

[developer-guy]

@naveensrinivasan I think we should create PAT to write another repository, the default actions token only has perms in the current repo 🙋🏻‍♂️ I asked to the maintainer of the GoReleaser project, he told me like that

[developer-guy]

We need to create one and store it on GitHub secret, maybe name it like 'GH_PAT', then we can use it 🙋🏻‍♂️

[azeemshaikh38]

To summarize, here's my take on this:

1. I would really really prefer not to go the PAT route. If this is doable, IMO we should wait until then.
2. If not, I'm ok biting the bullet for now and submitting this PR as long as there is some commitment from the goreleaser team that there will be a better and more secure alternative in the future.

[developer-guy]

Something which only allows write access to homebrew-tap repo.

This is exactly what I want right now.

[developer-guy]

I need a PAT specific for the homebrew-tap repository, as I said above, pleasesee.

[laurentsimon]

If we write a gorelease workflow in the homebrew-tap repo, we could use the default GitHub token without a hardcoded non-rotated PAT, right?

Something along the lines of:

1. workflows on ossf/scorecard runs upon release using gorelease. Instead of creating the tap in the workflow, we fire an event (via GH APIs?) to the ossf/homebrew-tap repo to trigger a workflow run. We ideally sign the request with cosign keyless and verify it from the ossf/homebrew-tap workflow.
2. The ossf/homebrew-tap workflow runs and verifies the signature. Then it clones the ossf/scorecard repo at the right commit and compile the code. Alternatively (and preferrably), it just pulls the new release and extract the already-compiled binaries.

Temporary solution: instead of firing an GitHub API from ossf/scorecard to ossf/homebrew-tap, we could start by simply manually creating a release on ossf/homebrew-tap and configure a gorelease workflow (as we currently do for scorecard): pulls the latest release from ossf/scorecard, extract the binaries and let gorelease do its magic.

Note1: I don't know what APIs we'd use to trigger a remote workflow. Maybe one to trigger repository_dispatch if it's feasible to do that from a remote repo's workflow. Could also just use a pull request (a little ugly though)...

Note2: I wonder if GitHub supports using OIDC between two workfloads on it own platform, i.e. between two repos' workflow https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect. I'll create an issue to ask them

[developer-guy]

PTAL @caarlos0 🙋🏻‍♂️

[naveensrinivasan]

Thanks! @azeemshaikh38 @laurentsimon Are you guys ok with merging this?

[github-actions]

Integration tests success for
[0ba7c02]
(https://github.com/ossf/scorecard/actions/runs/1552964964)

[laurentsimon]

Thanks! @azeemshaikh38 @laurentsimon Are you guys ok with merging this?

we're all a bit hesitant to use a write PAT because it's dangerous. In the spirit of OSSF and trying to help everyone improve their security posture, how about trying the following:

1. In this workflow, use the GitHub issue API and create an issue on ossf/homebrew-tap. For this a read-only PAT is needed, with repo_public permission only.
2. On the ossf/homebrew-tap repo, use the issues trigger for a new workflow. When a new issue comes in, it it has a pre-defined title and the author is the owner of the PAT, retrieve the latest release of scorecard, extract the binaries and give them to goreleaser. Or build scorecard fromm ossf/scorecard at the right commit hash if goreleaser does not support binaries. For this, we can use the default GitHub token with permission contents:write. Unlike a PAT, it's ephemeral. Even if someone were to find a way to trigger this workflow, we don't use untrusted input in the workflow, so it seems ok - essentially the build is parameterless like SLSA :)

I'd imagine we could even blog or tweet about it if it works and improves repo security. wdut?

[naveensrinivasan]

Now that we have the brew install scorecard https://github.com/ossf/scorecard#installation @developer-guy do we still need this?

[caarlos0]

Now that we have the brew install scorecard https://github.com/ossf/scorecard#installation @developer-guy do we still need this?

probably not...

[developer-guy]

Thanks! @azeemshaikh38 @laurentsimon Are you guys ok with merging this?

we're all a bit hesitant to use a write PAT because it's dangerous. In the spirit of OSSF and trying to help everyone improve their security posture, how about trying the following:

1. In this workflow, use the GitHub issue API and create an issue on ossf/homebrew-tap. For this a read-only PAT is needed, with repo_public permission only.
2. On the ossf/homebrew-tap repo, use the issues trigger for a new workflow. When a new issue comes in, it it has a pre-defined title and the author is the owner of the PAT, retrieve the latest release of scorecard, extract the binaries and give them to goreleaser. Or build scorecard fromm ossf/scorecard at the right commit hash if goreleaser does not support binaries. For this, we can use the default GitHub token with permission contents:write. Unlike a PAT, it's ephemeral. Even if someone were to find a way to trigger this workflow, we don't use untrusted input in the workflow, so it seems ok - essentially the build is parameterless like SLSA :)

I'd imagine we could even blog or tweet about it if it works and improves repo security. wdut?

it seems definitely more secure, but a bit complicated, isn't it? Maybe we can find another way to make it simpler (I still don't know how), @caarlos0 can help us here because it is more like a common problem, if we can find a way to do it, we can write a blog post about it to give people who might encounter with the same problem more information how they can solve the problem.

[naveensrinivasan]

@developer-guy This PR address the issue about brew install. For the permissions issues could you please open another issue? So I am closing it.