See parse_sig_created:
sig->sig_class = strtol (args, &tail, 0);
But:
<class> are 2 hex digits with the OpenPGP signature class.
Note that strtol is using a heuristic to detect the base (base is 0, see strtol(3)). For example, any signature class < 16 (e.g. 00) will have a leading zero, and will hence be interpreted as octal by strtol, so class 8 results in an parse error, and there are various values that now map to other values.
| rM GPGME | |||
| rMb1e5f3b18310 core: Fix SIG_CREATED status parsing for 0x1F sigs | |||
This is not easy to fix because it would break the GPGME API. Here
are the values we can expect:
| gpg | gpgme | |-----+-------| | 00 | 0 | | 01 | 1 | | 02 | 2 | | 10 | 10 | | 11 | 11 | | 12 | 12 | | 13 | 13 | | 18 | 18 | | 19 | 19 | | 1F | 1 | | 20 | 20 | | 28 | 28 | | 30 | 30 | | 40 | 40 | | 50 | 50 |
Given that sig_class is engine specific, the (wrong) decimal
representation is assumed by used. The actual bug here is that 0x1F
maps to 1; that is a Direct Key Signature can't be distinguished from
a Text Document Signature. However, both classes are used in
different domains and thus do not cause a real world problem.
However because a timestamp is expected as next item but 'F' is seen
instead of a space, GPGME falsely returns GPG_ERR_INV_ENGINE for 0x1F.
This can be mitigated by by detecting this case and mapping it to,
say, 131.
Eventually a new member is required to replace sig_class.
Thanks for reporting.