"pem" file of the release aren't PEM files

[ctron]

Taking a look at the "pem" files in the release section (like cosign-2.0.0.rc.1.aarch64.rpm-keyless.pem), those file aren't PEM files:

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN1akNDQWtDZ0F3SUJBZ0lVTGl0emNxWWhUSFhHekRHeFp1MVJ2V0hGUlRjd0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpNd01USTNNREV6T1RBeldoY05Nak13TVRJM01ERTBPVEF6V2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVtdUxnVnhEQXJtL0doZ1BRSjBFb29hNGlYUmJJRGZsZnZoa1cKSFlyT0NoYm9nbHVxTHpVYVQ1aFpQNWJ1L29QMDBSS1hJTDZUNEQvK05hak5FOTRXaHFPQ0FWOHdnZ0ZiTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVNNDFRClQ5clYvQ3JMY2gxV2k4SW5zVXZWVkNvd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d1BRWURWUjBSQVFIL0JETXdNWUV2YTJWNWJHVnpjMEJ3Y205cVpXTjBjMmxuYzNSdmNtVXVhV0Z0TG1kegpaWEoyYVdObFlXTmpiM1Z1ZEM1amIyMHdLUVlLS3dZQkJBR0R2ekFCQVFRYmFIUjBjSE02THk5aFkyTnZkVzUwCmN5NW5iMjluYkdVdVkyOXRNSUdKQmdvckJnRUVBZFo1QWdRQ0JIc0VlUUIzQUhVQTNUMHdhc2JIRVRKakdSNGMKbVdjM0FxSktYcmplUEszL2g0cHlnQzhwN280QUFBR0Y4T0RQQ0FBQUJBTUFSakJFQWlBWngzRSsrNjBhVjRsNAp0WGNVUXREbjAxTHo4ZkEzU1UzQ0tQOEJtaWRnUGdJZ1l2ekhxODJnZ0dGVnVzRUF1YlNZQ0xhUXJWTDFxNFEyCkgrQnZvQlNGWi9jd0NnWUlLb1pJemowRUF3TURhQUF3WlFJd0cxanFHZHNpUU1BVHZ2N3YzNW11N3czbVdUdTkKZ3BpbHhCaHFZdmE5a0toWHk5NmtWcW1iNkd2dEIwd0xJeTJ3QWpFQWdyNGswbm5mM1dWd3hjcTcxQ3FNaklvUwpGdGVSUXo4V0E3NDEwQm1EbHp3dlRvL1phL0lqRkwzTU5HUkJ0WTdVCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

But base64 encoded PEM files. From my point of view, if a .pem file is being distributed, it should actually be a PEM file, and not base64 encoded.

[developer-guy]

Hello @ctron, thanks for raising an issue; I think these files come from here as cosign use GoReleaser to sign binaries. I think at this point, as there is no manual process in here, we cannot do anything about these files, I guess, unless we edit the cosign code to make them base64 decoded, and this would be a breaking change, but I hand over that problem to @cpanato @dlorenc to get assistance.

[ctron]

unless we edit the cosign code to make them base64 encoded

I think the issue is that you actually base64 them "again". A PEM file already is base64 encoded, adding the header/footer lines. There is no need to base64 encode it twice.

Still, a .pem should contain the base64 encoded content of an actual PEM file.

Renaming the file to something other than .pem would make sense. Or actually storing the information in the PEM format.

As cosign sign-blob doesn't promise a PEM format, I guess is fine to not change cosign itself:

     --output-certificate string                                                                write the certificate to FILE

Just don't promise a PEM file :-)

[developer-guy]

sorry my typo, I just wanted to say "base64 decoded", not encoded 🤦

[ctron]

Btw, I just found a switch --b64 , which you can set as --b64=false to disable the base64 encoding.

[developer-guy]

Btw, I just found a switch --b64 , which you can set as --b64=false to disable the base64 encoding.

Yeah, that'd be super cool if we set this flag to keep our promises about pem files 🤞 but let's wait for @cpanato and @dlorenc's comments as well 😇

[developer-guy]

I've just checked that cosign worked both ways:

[developer-guy]

So basically, we can do that "--b64" trick in the GoReleaser file.

[znewman01]

Agreed that the output formats are a bit of a mess right now; this is something we're aware of and trying to fix. Fixing them by default will be a breaking change unfortunately, so we're planning to do this all at once. Basically, rather than output a certificate AND a signature AND a signed timestamp AND ... we'll stick them all in one .sigstore file.

My vote would actually be to rename the Goreleaser output to .pem.b64 to accurately describe its format, rather than changing the format which is a breaking change for automated verification workflows. Then, in the medium term, we'll start producing a .sigstore file and deprecate the weirdly-formatted output.

Relevant:

• Sigstore APIs/data formats: proto-first or JSON-first? community#136
• Adopt the sigstore bundle format in cosign protobuf-specs#13

[znewman01]

We decided that it would be a breaking change to rename these files, so we're trying to avoid that.

Instead, just documenting a little better. No great solution here unfortunately :/