To tarck this down I would also need the key. Can you create such a broken
message using one of the example keys (e.g. alfa@example.net)? IF so, feel free
to send it to me directly wk@gnupg.org - if the data is kind of sensitive, feeel
free to encrypt. Due to anti-spam meastures it is best to send a gzipped
tarball or any other gzipped data; or send me an URL.

I tracked it down with GPG (hadn't used that in 10 years).

Basically, if the CRC is alone on a line by itself, the function radix64_read in
armor.c returns -1 because of this line:

if( !n && !onlypad )
    rc = -1;

This cause iobuf.c:underflow to deallocate the filter, leaving the file_filter
alone. So next time it reads using the file_filter and gets the '-----END PGP
MESSAGE-----'.

If the CRC is not a line by itself, the armor_filter is not deallocated, but
reads to the end of the file first, which deallocates the file_filter, then says
it doesn't have any more data (rc=-1,len=0).

I am inclined to fix this by putting this check towards the end of radix64_read:

Line 929-941 of armor.c:
#endif

}

if(n==0)
  onlypad=1;

    }
}

if( !n && !onlypad )
    rc = -1;

*retn = n;
return rc;

}

This fixes my issue.

Included is an example of a message that once encrypted causes problems. The
message was encrypted with a public key but not signed.

Thanks for the excellent description.