Page MenuHome GnuPG

GPGME incorrectly parses the signature class in SIG_CREATED status lines
Open, NormalPublic

Description

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.

Event Timeline

werner triaged this task as Normal priority.Sep 29 2022, 8:30 AM
werner added a project: gpgme.
werner added a subscriber: werner.

I assume this is gpgme master. Please write proper bug reports.

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.

Let's don't forget that we need to have a sig_class replacement.