Page MenuHome GnuPG

GPGSM: Duplicated IMPORT_OK status lines emitted
Open, LowPublic

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:

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

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.