Here are changes to fix the behavior:

The 0003- prevents SEGV.
The 0004- allows to keep processing data by skipping the erroneous part.

I definitely prefer 0004. I am not so sure on the use of -1 as return code. I know that we use it for legacy reasons but it does not feel correct. Maybe add an arg int *skipme to the function so that we can selectively skip this packet. Note that I have not fully evaluated the patch; the -1 might just be right.

I see your point. I am afraid adding skipme causes a larger changes.

I propose adding more change over 0003- and 0004-.

That is, let us make the return value consistent, although it will change the existing behaviors a bit; When gpg parses unknown algorithm and the packet is too much, it will be skipped just like too long hashed/unhashed data.

We should keep in mind that we set an arbitrary limit for the [un]hashed areas. They are actually allowed to be larger. At some point in the future we might want to lift that limit again or add another algorithm. We need to take care that we don't drop the signature packet but merely don't use it. The packet needs to be storable in our keyring even if we cannot parse it now correctly. This is different from a broken packet, which is better dropped.

Reconsidering this all I don't think it makes any sense to distinguish between (-1) and GPG_ERR_INV_PACKET. We use (-1) for a too short read of the hashed or unhashed area (premature eof). INV_PACKET is for unknown versions, too much data (arbitrary limit), bad parameters, and underflow. Let's forget my previous comment and always use INV_PACKET.

In fact (-1) is used by all callers of parse_packet to indicate EOF.