Ambiguous discussion of detached signature in containers-signature.5.md about image HOT 3 CLOSED

Thanks for your report.

Pedantically, I’d argue that the spec already implies this by referring to RFC 4880 section 11.3. , which refers to specific binary packet formats, and does not talk about ASCII armor; but it’s clearly not explicit enough.

Pragmatically, much more important is that the implementation chosen by the containers_image_openpgp build tag has always rejected ASCII-armored signatures, so they were not widely interoperable (E.g. CRI-O is rejecting them in the default build).

So, I am proposing #1854 .

As much as I would like to ask for (or provide) handling for content of this sort,

Why is it useful?

To me it seems to only add unnecessary ambiguity, implementation complexity, and data size, for no end-user benefit; if anything, it adds risk because it makes it easier for users to see, and potentially rely on, the contents of the signature without actually verifying its authenticity.

I may well be missing something; what is it?

(Arguably, “we have tons of content signed that way” could count as a good enough reason alone… but, it’s, shall we say, not an elegant reason.)

from image.

BTW if past signed content is the only reason, I wouldn’t object too strongly to detecting and allowing the ASCII-armored signatures through, and letting GPG deal with them the way it has done; that adds little to no signature verification risk. I would be much less happy about actually adding ASCII armor implementation to the containers_image_openpgp code path, that would directly be adding rarely-used code to a critical signature verification code path.

from image.

#1854 is a satisfactory resolution. Thanks, @mtrmac!

from image.