Signature validation of ASCII armored OpenPGP signatures fail

[drGrove]

When an atomic signature is ASCII armor encoded, validation of it fails due to not being able to determine the format.

skopeo 1.21.0

-> skopeo --debug copy docker://stagex/core-bash:5.2.37 dir:sx-core-bash
FATA[0002] copying system image from manifest list: Source image rejected: parsing signature https://sigs.stagex.tools/stagex/core-bash@sha256=5b598c14eef61148baf3f5a2830a214a5985b5d3544b019e3d0ed53c6b66989a/signature-2: unrecognized signature format, starting with binary 0x2d 

Which comes from signature.go FromBlob.

sq packet dump signatures/stagex/core-bash@sha256=5b598c14eef61148baf3f5a2830a214a5985b5d3544b019e3d0ed53c6b66989a/signature-2
Compressed Data Packet, old CTB, indeterminate length
│   Algorithm: ZIP
│
├── One-Pass Signature Packet, old CTB, 13 bytes
│       Version: 3
│       Type: Binary
│       Pk algo: EdDSA
│       Hash algo: SHA512
│       Issuer: DD9F5D50CAA0BAD4
│       Last: true
│
├── Literal Data Packet, new CTB, 237 bytes
│       Format: Binary data
│       Timestamp: 2026-01-29 02:39:57 UTC
│       Content: {"critical":{"identity":{"docker-referen...
│
└── Signature Packet, old CTB, 117 bytes
        Version: 4
        Type: Binary
        Pk algo: EdDSA
        Hash algo: SHA512
        Hashed area:
          Issuer Fingerprint: 2093E332AE21416C536355C0DD9F5D50CAA0BAD4
          Signature creation time: 2026-01-29 02:39:57 UTC
        Unhashed area:
          Issuer: DD9F5D50CAA0BAD4
        Digest prefix: 1F84
        Level: 0 (signature over data)

User had ascii armor enabled by default

# gpg.conf
armor

We generate our signatures using gnupg directly, we can change our script to include --no-armor which will take precedence over the users config, but I imagine we won't be the last to come across this.

We have dearmored the signatures on our lookaside server, but here was the previous ASCII armored one

[mtrmac]

Thanks for your report.

I think the most pedantic reading of https://github.com/containers/container-libs/blob/38ab7bf87d7a20e1a7ecc27193cf17d51c806f9e/image/docs/containers-signature.5.md#openpgp-signature-verification is that an armored message is not expected, but the spec does not say so directly.

The code you pointed at was “only” added in 2022; before, it’s possible that the GPG backend was accepting armored signatures — but the OpenPGP backend never accepted armored signatures since it was added in 2017.

So I think it makes more sense to explicitly document ASCII-armored signatures to be invalid. (Yes, there is #307, but that’s explicitly violating the spec for other reasons anyway … and the linked code never came up; so it’s possible that this just never worked other than maybe a very special caller.)

Care to write a PR that clarifies the documentation?