Cosign

[hslatman]

Closes #69

[fabpot]

Thank you for working on this.

Would it make sense to add a small note in the README to tell people how they can verify their binaries?

[hslatman]

@fabpot: that absolutely makes sense!

There are a couple of things to consider going forward and I think these are things that need your approval. I've described these in the issue: #69 (comment). Decision made will also affect the instructions for the user.

It seems the workflow execution failed in this repo. I think you approved of it manually? It seems that cosign didn't have access to an identity token and started an OIDC flow as part of the GH action. This probably has something to do with the GITHUB_TOKEN not having the right permissions, but I'm not sure about it. I did a test run on my fork and there it did continue without doing an OIDC device flow.

[fabpot]

Regarding your questions, I would do the simplest thing for our users, so signing the binaries themselves. For SBOMs, if nobody asked for them, let's not do that for now. I would like to keep this PR as simple as possible.

[hslatman]

@fabpot: I've addressed your comments. Is the README OK like this?

I haven't been able to test the full action flow when using a version tag, so I'm curious to see if it works as expected 🙂

[fabpot]

The build fails.

[hslatman]

@fabpot: it's likely due to using GH_PAT instead of GITHUB_TOKEN. I don't think a PAT can be used to get an identity token; the temporary GITHUB_TOKEN can.

Do you want to go forward using the GH_PAT for other purposes? If so, I'll try to pass the GITHUB_TOKEN to just the signing operation, so that it can get an identity token. Otherwise I'll replace GH_PAT with the GITHUB_TOKEN and then it should work.

To be complete: these tokens wouldn't be necessary if I didn't use the keyless method; a private key with password would be enough instead. But from what I gather, keyless will likely be the recommended method in the future.

[fabpot]

Let's keep it simple by using the GITHUB_TOKEN everywhere then.

[hslatman]

@fabpot: changed it. Let's see if it works now. I don't know if your PAT had certain permissions that the GITHUB_TOKEN currently does not, so that could cause an issue. Updating the permissions with the ones required should help then.

[hslatman]

Same error 😕

EDIT: I suspect it's related to this: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#how-the-permissions-are-calculated-for-a-workflow-job

[fabpot]

I've just created a branch with your changes to see if that would work and indeed, that works well: https://github.com/symfony-cli/symfony-cli/runs/5065888193?check_suite_focus=true

[fabpot]

Thank you @hslatman

[fabpot]

@hslatman But unfortunately, the released failed: https://github.com/symfony-cli/symfony-cli/runs/5065962537?check_suite_focus=true
Can you have a look? Do we really need the proxy?

[hslatman]

I noticed; too bad 😞

Using the Go module proxy is not necessarily required, no. Disabling that in the GoReleaser config should make it run.

I tried it before and thought it was because the tag wasn't on the original repo. That apparently wasn't the issue. It's likely due to Go module versioning. I'll have a look at doing that the proper way, but for now disabling the proxy is OK.

EDIT: PR is here: #85

[hslatman]

I'll fix the issue with the Homebrew tap.

EDIT: this should fix it: #86