In some obscure cases (e.g. race conditions), gpg-agent dies and isn't available when enigmail tries to ask gnupg to import a secret key. Enigmail seems to believe that the secret key was successfully imported in that case, even though gpg failed to import the secret parts of the key.
I ran into this with some older versions of GnuPG (e.g. the
heavily-patched GnuPG 2.1.18 in debian stretch) during the enigmail test
suite (enigmail version 2.0.8), which does a lot of rapid creation and
tear-down of GnuPG homedirs.
To detect this properly, the GnuPG status output indicates the issue in
IMPORT_RES, by indicating a difference between sec_read and sec_imported
(see the documentation for IMPORT_RES in GnuPG's DETAILS file).
Enigmail doesn't appear to compare these values when it does an import.
here's an example of this failure from the test suite during such a race
condition, showing sec_read=1 and sec_imported=0 (apparently GnuPG also
returns a non-zero error code, but enigmail ignores it):
-------------
2018-10-04 20:44:21.826 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8
--display-charset utf-8 --no-auto-check-trustdb --no-verbose --status-fd 2
--no-auto-check-trustdb --import /home/user/src/enigmail/enigmail/package/tes\
ts/resources/dev-strike.sec
2018-10-04 20:44:21.856 [DEBUG] enigmail> DONE
2018-10-04 20:44:21.856 [DEBUG] execution.jsm: EnigmailExecution.execCmd:
exitCode = 2
2018-10-04 20:44:21.856 [DEBUG] execution.jsm: EnigmailExecution.execCmd:
errOutput = gpg: keybox
'/home/user/src/enigmail/enigmail/tmp/.gnupgTest1/pubring.kbx' created
gpg: /home/user/src/enigmail/enigmail/tmp/.gnupgTest1/trustdb.gpg: trustdb
created
[GNUPG:] KEY_CONSIDERED 65537E212DC19025AD38EDB2781617319CE311C4 0
gpg: key 781617319CE311C4: public key "anonymous strike
<strike.devt...@gmail.com>" imported
[GNUPG:] IMPORTED 781617319CE311C4 anonymous strike <strike.devt...@gmail.com>
[GNUPG:] IMPORT_OK 1 65537E212DC19025AD38EDB2781617319CE311C4
[GNUPG:] KEY_CONSIDERED 65537E212DC19025AD38EDB2781617319CE311C4 0
gpg: key 781617319CE311C4/781617319CE311C4: error sending to agent: No such
file or directory
gpg: error building skey array: No such file or directory
gpg: Total number processed: 1
gpg: imported: 1
gpg: secret keys read: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0
2018-10-04 20:44:21.856 [DEBUG] errorHandling.jsm: parseErrorOutputWith: status
message:
gpg: keybox '/home/user/src/enigmail/enigmail/tmp/.gnupgTest1/pubring.kbx'
created
gpg: /home/user/src/enigmail/enigmail/tmp/.gnupgTest1/trustdb.gpg: trustdb
created
[GNUPG:] KEY_CONSIDERED 65537E212DC19025AD38EDB2781617319CE311C4 0
gpg: key 781617319CE311C4: public key "anonymous strike
<strike.devt...@gmail.com>" imported
[GNUPG:] IMPORTED 781617319CE311C4 anonymous strike <strike.devt...@gmail.com>
[GNUPG:] IMPORT_OK 1 65537E212DC19025AD38EDB2781617319CE311C4
[GNUPG:] KEY_CONSIDERED 65537E212DC19025AD38EDB2781617319CE311C4 0
gpg: key 781617319CE311C4/781617319CE311C4: error sending to agent: No such
file or directory
gpg: error building skey array: No such file or directory
gpg: Total number processed: 1
gpg: imported: 1
gpg: secret keys read: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0
2018-10-04 20:44:21.856 [DEBUG] errorHandling.jsm: importOk: key imported:
65537E212DC19025AD38EDB2781617319CE311C4
-------------
When enigmail attempts to actually import a key, it ought to notice if
the secret part of the subkey is not imported, and to raise that as an
error to the rest of the codebase, so that (a) the test suite can fail
earlier, and (b) the user is aware that something they might have been
expecting from the import didn't actually happen.
Sorry that i don't have a specific patch to propose here yet, but i'm
happy to review if you want to propose a patch.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
