** Description changed: [ Impact ] - gpg in Noble (2.4.4) and Resolute (2.4.8) exits with code 2 when verifying - a clearsigned file whose armored signature has no CRC24 checksum line and - no base64 "=" padding (i.e. signature length divisible by 3). The signature - is reported as "Good signature", but gpg also prints "no valid OpenPGP data - found." and exits non-zero. + gpg in Noble (2.4.4-2ubuntu17.6) and Resolute (2.4.8-4ubuntu3.1) fails to + verify some valid clearsigned files. It reports "Good signature", but also + prints "no valid OpenPGP data found" and exits with code 2. Any tool that + relies on the exit code treats the file as badly signed. - The CRC24 line is optional per RFC 9580, so these files are valid. This - breaks tools that rely on gpg's exit status, e.g. reprepro / Landscape 24.04 - mirroring https://packages.microsoft.com/ubuntu/26.04/prod/dists/resolute/InRelease. + This was reported by a user mirroring the Microsoft resolute repository with + Landscape 24.04 on Noble, which uses reprepro. Mirroring fails because the + InRelease file can never be verified. The signature in an InRelease file is + base64 encoded and may end with a CRC24 checksum line ("=XXXX"). RFC 9580 makes + this line optional, and Microsoft's signer leaves it out. The gpg versions in + Noble and Resolute only consider the signature data complete when they see an + "=" character, which normally comes from either base64 padding or the CRC24 + line. If the signature length is a multiple of 3, there is no padding. + So with no CRC24 line, there is no "=" at all, and gpg wrongly decides that no + OpenPGP data was found. - Fixed upstream under https://dev.gnupg.org/T7071. Stonking is not - affected. + The Microsoft resolute repository is signed with an RSA-4096 key, giving a + 543-byte signature (a multiple of 3), so it triggers the bug. The jammy and + noble repositories are signed with an RSA-2048 key, giving a 287-byte signature + that ends with "=" padding, so they verify fine. + + On Noble there is a second problem: gpg does not recognize the + "-----END PGP SIGNATURE-----" line when there is no CRC24 line and tries to + decode it as base64. This adds "invalid radix64 character" and "invalid packet + (ctb=10)" errors to the output. + + The fix backports the upstream fixes for GnuPG bug T7071 [1]. Resolute gets 3 + commits [3][4][5] that mark the data as found as soon as any of it is decoded, + and that detect the end of the armor correctly when there is no CRC24 line. + Noble also gets an earlier commit [2] that makes gpg recognize the end of the + armor without a CRC24 line. Stonking (2.4.9-4ubuntu3) already includes all four + commits. [ Test Plan ] - TBD + ** Setup Test Environment ** + + 1. Launch a container for the release being tested: + $ lxc launch ubuntu:<RELEASE> gpg-test + $ lxc shell gpg-test + + 2. Download the Microsoft noble and resolute InRelease files: + $ wget -O InRelease-noble https://packages.microsoft.com/ubuntu/24.04/prod/dists/noble/InRelease + $ wget -O InRelease-resolute https://packages.microsoft.com/ubuntu/26.04/prod/dists/resolute/InRelease + + 3. Import the Microsoft signing keys: + $ curl -fsSL https://packages.microsoft.com/keys/microsoft.asc \ + | gpg --import + $ curl -fsSL https://packages.microsoft.com/keys/microsoft-2025.asc \ + | gpg --import + + ** Verify the Bug ** + + 4. Verify the noble InRelease (signature has "=" padding, not affected): + $ gpg --verify InRelease-noble; echo "rc=$?" + + Observed result: + gpg: Good signature from "Microsoft (Release signing) <[email protected]>" [unknown] + rc=0 + + 5. Verify the resolute InRelease (no padding and no CRC24 line): + $ gpg --verify InRelease-resolute; echo "rc=$?" + + Observed result on Noble: + gpg: invalid radix64 character 2D skipped (x10) + gpg: [don't know]: invalid packet (ctb=10) + gpg: Good signature from "Microsoft Corporation - General GPG Signer <[email protected]>" [unknown] + gpg: no valid OpenPGP data found. + rc=2 + + Observed result on Resolute: + gpg: no valid OpenPGP data found. + gpg: Good signature from "Microsoft Corporation - General GPG Signer <[email protected]>" [unknown] + rc=2 + + ** Verify the Fix ** + + 6. Install patched gnupg2 package and verify the noble InRelease still works: + $ gpg --verify InRelease-noble; echo "rc=$?" + + Observed result: + gpg: Good signature from "Microsoft (Release signing) <[email protected]>" [unknown] + rc=0 + + 7. Verify the resolute InRelease: + $ gpg --verify InRelease-resolute; echo "rc=$?" + + Observed result on Noble and Resolute: + gpg: Good signature from "Microsoft Corporation - General GPG Signer <[email protected]>" [unknown] + rc=0 + No "invalid radix64", "invalid packet" or "no valid OpenPGP data found." + lines. [ Where problems could occur ] - TBD + The change is in g10/armor.c, which parses all OpenPGP ASCII-armored input for + both gpg and gpgv. This includes clearsigned files, detached signatures, + armored keys and encrypted messages. A regression here could cause valid + armored data to be rejected, or the end of the armor to be detected in the + wrong place, causing verification, import or decryption failures. + + The patches only change what happens when the armor has no CRC24 line, or when + the end-of-armor line is reached. Input with a valid CRC24 line goes through + the same code path as before. The end-of-armor check is also made stricter so + that it only matches "-----END " at the start of a line, which could affect + malformed input that relied on the looser check. [ Other Info ] - TBD + The patches are cherry-picked from the upstream GnuPG 2.4 branch, the same + commits that Stonking has in debian/patches/from-24/. Commits [4] and [5] must + be applied together: [5] fixes a regression introduced by [4] when no CRC24 + line is present. + + Test packages for both Resolute and Noble were built and are available in the + following PPA: + https://launchpad.net/~munirsid/+archive/ubuntu/lp2173093 + + [1] https://dev.gnupg.org/T7071 + [2] https://github.com/gpg/gnupg/commit/0eefa08295b2d19f6f3066b925e001833934a1f0 + (Noble only, already in Resolute) + [3] https://github.com/gpg/gnupg/commit/3c728ccd54df3fd4066588f6e2ba2d60968adc7f + [4] https://github.com/gpg/gnupg/commit/869cc5027c72b4d4cdd52eb4da66340166c3c211 + [5] https://github.com/gpg/gnupg/commit/8a597f8b389881ac61a3b472617a600dd493e821
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2173093 Title: gpg --verify fails with "no valid OpenPGP data found" on armored signatures without CRC24 checksum or base64 padding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/2173093/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
