Signer creates openssl-incompatible, encoded signature files

[dragetd]

BASE64 does not impose linebreaks. But the OpenSSL implementation to decode BASE64 (used in our verification scripts for the jre bundles) expects a PEM-like format with 80 chars per line: https://wiki.openssl.org/index.php/Base64#base64_uses_PEM_80_characters_per_line

Should we stop using OpenSSL for decoding BASE64 in the scripts or change the signer code? Generally I'd prefer the first option, but if we consider the linebreaks as part of the 'signature-format', the new signer implementation would be sort-of breaking change.

The more backward-compatible solution would be to consider this as a bug in the new signer and spit out signatures compatible by OpenSSL.

The relevant line is: https://github.com/setlog/trivrost/blob/336202e4b6e1aa0be597a61a69591f73f2b23142/cmd/signer/main.go#L54

Such an output fails to decode with OpenSSL:

openssl base64 -d -in ${item}/bundleinfo.json.signature -out /tmp/~signature.decoded

(Zero length file created)

[MMulthaupt]

The actual problem is that the generated file contains no line breaks at all. The hack you are looking for is:

printf "%s\n" "$(<${item}/bundleinfo.json.signature)" | openssl base64 -d -out /tmp/~signature.decoded

[dragetd]

Not looking for a hack ;-P I'd prefer the signer to output PEM compatible files. If that is OK with you, I'll do a PR.

[dragetd]

@dchaykin Do you want to have a go? Creating PEM compatible files with linebreaks after 80 chars?

[dragetd]

Marc correctly said, that the encoded format like we have it already is the 'trivrost-format'. Eventho teh PEM-80-chars-per-line format is in theory compatible to our, this is not a simple changed.

Moved to future!