Hi, I'm integrating Gpg4Win (a GnuPG distribution for Windows) for a customer. Gpg4Win is using Kleopatra as its primary key manager.
Kleopatra exposes a problem of GnuPG on Windows (see bug report https://bugs.gnupg.org/gnupg/issue2135) : importing a big pubring (> 200 public keys) does not import all the keys. The import stops after the n first ones (n may vary). It eventually works after retrying as many times as needed, but that is not a solution. If I understand well what happens: 1. User tells Kleopatra to import a big keyring. 2. Kleopatra starts the gpg job to do that, which works in background. 3. The gpg job is updating files in GNUPGHOME. 4. Kleopatra starts a KeyListJob to refresh the UI, through a gpg command. Somehow, the «keylist» gpg process reads some files and at some point this prevents the « import » gpg process from doing its work. We are trying to fix that in gnupg, but I'm also looking for alternate solutions (hopefully easier to implement). I'm not yet familiar with Kleopatra's internals, but my thoughts have been : 1. Remove the KeyListJob (I guess the treeviews will not be updated then, so a bad idea, but who knows...), 2. Do not trigger a KeyListJob when launching an import job, 3. Wait for the end of the import job to trigger the KeyListJob Do you have any insights on possible workarounds or mitigations ? Thank you, Olivier Serve olivier.se...@atos.net >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
