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 | |||
| 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.