Page MenuHome GnuPG
Create Task
Maniphest T4480

GPGSM: Duplicated IMPORT_OK status lines emitted
Open, LowPublic
Actions

Description

This creates a weird GPGME result where num_considered is smaller then the import result and the import result has 6 entries for three certs.

Example file:

aheinecke-2018.pem7 KBDownload

gpgsm --status-fd 1 --import ~/certs/aheinecke-2018.pem
[GNUPG:] IMPORT_OK 0 13EDC882410E770C854B1CCEBB11CE8CADF09832
[GNUPG:] IMPORT_OK 0 80C65EB68E40D7A15F65AE4A3F4AE6B073EB5FC2
[GNUPG:] IMPORT_OK 0 4E348D97A2810B20445EA9243989CCD6A0822B40
[GNUPG:] IMPORT_OK 0 80C65EB68E40D7A15F65AE4A3F4AE6B073EB5FC2
[GNUPG:] IMPORT_OK 0 4E348D97A2810B20445EA9243989CCD6A0822B40
[GNUPG:] IMPORT_OK 0 4E348D97A2810B20445EA9243989CCD6A0822B40
gpgsm: total number processed: 3
gpgsm:              unchanged: 3

Prio low as I'm not sure if it is a regression and it does not seem to do harm to current applications using this.

Details

Version
master

Event Timeline

aheinecke created this task.May 3 2019, 10:44 AM
aheinecke added a project: S/MIME.
• gniibe added a subscriber: • gniibe.Aug 22 2019, 3:52 AM

It appears (for me) correct behavior.

It is emitted, because it is imported multiple times.

At check_and_store function in gpgsm/import.c, it is emitted after keydb_store_cert is called (https://dev.gnupg.org/source/gnupg/browse/master/sm/import.c;ce403c74dbc9c027b823910f22338269e625f76f$203)

It is because it walks up the chain by gpgsm_walk_cert_chain, and all certificates up the chain are recursively check_and_store-ed.

So, it is like:

13ED...
    80C6... by recursive call
    4E34... by recursive call
80c6...
    4E34... by recursive call
4E34...

If it (the report by recursive call) is not expected, we can stop calling print_import_status when stat==NULL.