Cosign creates private key file that isn't working

[Pythoner6]

Cosign 2 (which is what's being used now in the alpine container) seems to produce a different private key file that isn't working, it's PEM header starts with:

-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----

compared to from previous versions:

-----BEGIN ENCRYPTED COSIGN PRIVATE KEY-----

This seemingly leads to the following error during the signing step:

Error: signing [ghcr.io/pythoner6/ublue-custom@sha256:8c111a115fcf428804f1a43786afbb1633d156572e954432c37ca751a7d7b291]: getting signer: reading key: invalid pem block
main.go:74: error during command execution: signing [ghcr.io/pythoner6/ublue-custom@sha256:8c111a115fcf428804f1a43786afbb1633d156572e954432c37ca751a7d7b291]: getting signer: reading key: invalid pem block
Error: Process completed with exit code 1.

[bsherman]

Yep... I've also run into this.

The latest cosign github action is now v3.0.1 or v3.0.2 or something ... and it does seem cosign 3 is not backward compatible with cosign 2 keys.

The latest cosign github action is now v3.0.1 or v3.0.2 or something ... and it does seem cosign action 3 (using cosign 2) is not backward compatible with cosign 1 keys.

Though, I didn't experience this specifically with the create-ublue-image script, rather by having an older key in my repo and then upgrading the cosign action and then having troubles.

[xynydev]

seems to produce a different private key file that isn't working

For me, it creates a key starting with -----BEGIN ENCRYPTED COSIGN PRIVATE KEY-----, but the git add/push step is broken.
Once I manually pushed, the build worked flawlessly.

Edit: #5 was the issue I was experiencing. After it being ✨ magically sorted out, ~~I'm having no signing issues as of right now. ~~

Edit2: Apparently after #5 my key now starts with -----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----. It's the latest version (I know this, the latest commit has been applied).
And it breaks signing...

Issue succesfully reproduced, yay.

Edit3: This being based on alpine, there's no way to go back to cosign v1 (I'm not sure if that even is the intended direction to take). It's odd then that it doesn't work as from what I understand from yall, the action is using v2 too?

But, here's our culprit sigstore/cosign#2735 (new change in v2.0.1). It seems that cosign installer defaults to that version (newest) too (sigstore/cosign-installer@9e9de22), so I'm not sure why it wouldn't work, as per my understanding, both the GHA and this container image should be using the same version of cosign...

Edit4: I changed SIGSTORE to COSIGN in my cosign.key and now I'm getting another error.

I think this is upstream cosign bugs now... Maybe the GHA version in startingpoint should be pinned to v1 for the time being...

[xynydev]

Update: Startingpoint has now been updated to use the same signing steps in build.yml as main does, and I managed to get a clean repo from the tool to build https://github.com/EinoHR/ublue-test/actions/runs/4789710128/jobs/8517904007

I think we're done here.