In gpg/g10/armor.c, I found:
/* No CRC at all is legal ("MAY") */
But with current implementation, it actually requires a character = after base64 encoded data.
It's good to support no CRC checksum at all (I mean, with no =) in ASCII armored data.
In the specification, it says:
The checksum with its leading equal sign MAY appear on the first line after the base64 encoded data.
My interpretation is that the checksum (= plus three characters) is optional.
| rG GnuPG | |||
| rG8a597f8b3898 gpg: Fix armor parsing when no CRC is found. | |||
| rG3c728ccd54df gpg: Fix handling with no CRC armor. | |||
| rGb7aa3f5e320d gpg: Fix armor parsing when no CRC is found. | |||
| rGb1857a2836c9 gpg: Fix handling with no CRC armor. | |||
| rG0eefa08295b2 gpg: Allow no CRC24 checksum in armor. | |||
| rG3a344d623652 gpg: Allow no CRC24 checksum in armor. | |||
The following patch works.
diff --git a/g10/armor.c b/g10/armor.c index b47c04ab3..81af15339 100644 --- a/g10/armor.c +++ b/g10/armor.c @@ -1031,10 +1031,10 @@ radix64_read( armor_filter_context_t *afx, IOBUF a, size_t *retn, checkcrc++; break; } - else if (afx->dearmor_state && c == '-' + else if (c == '-' && afx->buffer_pos + 8 < afx->buffer_len && !strncmp (afx->buffer, "-----END ", 8)) { - break; /* End in --dearmor mode. */ + break; /* End in --dearmor mode or No CRC. */ } else { log_error(_("invalid radix64 character %02X skipped\n"), c);
It's better to keep accepting a single = for backward compatibility for no CRC.
Applied to master. If no problem will be found, I'll apply to 2.4 branch too.
Let's see.
When CHECKCRC == 0 (no CRC), ->any_data was not set, resulted
no valid OpenPGP data found.
wrongly.
Reported gnupg channel on IRC.
An ascii armored file in question was: https://github.com/syncthing/syncthing/releases/download/v1.29.2/sha256sum.txt.asc
Hello,
this marked as fixed in 2.4.7. However afaict only one of the two patches made it to STABLE-BRANCH-2-4, b1857a2836c9a91ef4e359ef7ba949b54c77219d did not.
This shows up when trying to verify to verify
syncthing-source-v2.0.0-beta.5.tar.gz.asc /
syncthing-source-v2.0.0-beta.5.tar.gz ( from
https://github.com/syncthing/syncthing/releases/tag/v2.0.0-beta.5 ) against the attached keyring
ametzler@argenau:/tmp/SY$ /tmp/GNUPG2/2.4.7//usr/bin/gpgv --homedir /tmp/SY/gpghome --keyring /tmp/SY/both.gpg syncthing-source-v2.0.0-beta.5.tar.gz.asc syncthing-source-v2.0.0-beta.5.tar.gz ; echo exit $? gpgv: no valid OpenPGP data found. gpgv: Signature made Fr 04 Apr 2025 19:29:52 CEST gpgv: using RSA key FBA2E162F2F44657B38F0309E5665F9BD5970C47 gpgv: Good signature from "Syncthing Release Management <release@syncthing.net>" gpgv: Signature made Fr 04 Apr 2025 19:29:52 CEST gpgv: using RSA key 37C84554E7E0A261E4F76E1ED26E6ED000654A3E gpgv: Good signature from "Syncthing Release Management <release@syncthing.net>" exit 2
whereas 2.4.7 with the missing patch or 2.5.4 and later yield:
ametzler@argenau:/tmp/SY$ /tmp/GNUPG2/2.5.4//usr/bin/gpgv --homedir /tmp/SY/gpghome --keyring /tmp/SY/both.gpg syncthing-source-v2.0.0-beta.5.tar.gz.asc syncthing-source-v2.0.0-beta.5.tar.gz ; echo exit $? gpgv: Signature made Fr 04 Apr 2025 19:29:52 CEST gpgv: using RSA key FBA2E162F2F44657B38F0309E5665F9BD5970C47 gpgv: Good signature from "Syncthing Release Management <release@syncthing.net>" gpgv: Signature made Fr 04 Apr 2025 19:29:52 CEST gpgv: using RSA key 37C84554E7E0A261E4F76E1ED26E6ED000654A3E gpgv: Good signature from "Syncthing Release Management <release@syncthing.net>" exit 0
Using --enarmor and removing the checksum I sometimes get
gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped
with the latest version 2.5.17.
Example:
-----BEGIN PGP ARMORED FILE----- Comment: Use "gpg --dearmor" for unpacking QW5kIGRvIHlvdSB0aGluayAoZm9wIHRoYXQgSSBhbSkgdGhhdCBJIGNvdWxkIGJl IHRoZSBTY2FybGV0IFB1bXBlcm5pY2tlbD8K -----END PGP ARMORED FILE-----
rG62b8bf2f introduced the regression. The intent of the fix was about comparison of -----END , which has nine characters.
But it also added afx->buffer_pos ==1, that affected.
radix64_read is called twice at the end of the armor. Firstly, it detects the tail and returns the contents with *RETN = N > 0. And then,
it is called again and it returns -1 for EOF. For the second call, afx->buffer_pos should be decremented in the first call.
Fixed in rGb7aa3f5e320d: gpg: Fix armor parsing when no CRC is found.