Kleopatra does not import all the keys from an .asc file

Gpg4win help-en
1

Hi,

I have an .asc file that is an export of 488 gpg public keys. The file is on the local disk. System is Windows 7.

When I import it into Kleopatra, it only imports a part of them. I can retry and it will import more and more keys until all the file is imported. So it kind of works, but in a very clunky way.

It looks like the file couldn’t be read in one go.

Has this problem been reported before ?

2

Hi Olivier,

so far I am not aware that this problem has been reported before,
thanks for writing it up!

The next step would be to make it reproducable and then report it on bugs.gnupg.org
or bugs.kde.org. Do you have any large cert file (with public keys) that could be used
to reproduce?

Best,
Bernhard

3

Hi Oliver,

No It hasn’t been reported yet. I couldn’t reproduce this on GNU/Linux either but I can reproduce it on Windows exactly as you describe.

The problem appears to be that kleopatra starts a keylist job while the import is running. If you shutdown Kleopatra and import on the command line using

gpg2 --import

It works.

I’ve opened: https://bugs.gnupg.org/gnupg/issue2135
for this.

Do you have an account on that tracker? You might want to put yourself in the nosy there to follow the progress on this bug.

Thanks for the report!

Andre

4

I took a look at the bug you created

If I understand well:

  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 is watching for changes in GNUPGHOME. It detects the changes made by the gpg job and starts an update job to refresh the UI. It does this by using a “keylist” command of GnuPG, which interrupts the gpg import job (Windows file locking subtleties I guess).

I have not looked at the Kleopatra code yet, but maybe it would be possible to inhibit (or defer) the keylist job when another gpg job is running (at least on Windows) ?

5

Yes this sums it up. Inhibiting the keylist from Kleopatra would work, but gpgme is supposed to be threadsave and it works on GNU/Linux. So it’s very likely a bug in the locking mechanism of GnuPG on Windows that should be fixed.

If the “agressive” keylisting of kleopatra is such a good idea is a different question. I think the intention was that if you e.g. make changes to your trustlist.txt for S/MIME certs that kleo should pick those up automatically. This can be done more intelligently e.g. by still monitoring the trustlist.txt and the keyrings but only starting a keylist job if a file has been changed and not changed again in the last second or so. To avoid trying to work with a moving target.

6

Hello,

We have tested the new 2.3.0 version.
Keys import operation works now well in 90% of case. Unfortunately, we have random failed imports (only a part of keys are imported) on some workstations we do not understand.
We have set the logs (Kleo & GPG), but their contents seems not to be significant.

We have also seen that import operation using the command line (gpg --import <file.asc>) always fails in the same way if Kleopatra is running.
The error is : permission denied when renaming pubring.gpg to pubring.bak in AppData/Roaming/gnupg directory

Thank you for your help,

2-log_gpg.7z (16.5 KB)

7

Sorry to hear that it’s still a problem. Of course, the underlying problem is not fixed and I’ve added a comment in issue2135 how to reproduce this even without Kleopatra. But importing through Kleopatra should work now.

That the import on the Commandline fails if kleopatra is running is expected. As the workaround for the bug was to disable Kleopatra’s automatic keylisting during the import in Kleopatra. If you import from the commandline kleopatra still does the keylisting and interrupts the import.

It might be interesting to see the debug output from Kleopatra (You can see it with DebugView https://technet.microsoft.com/en-us/sysinternals/debugview.aspx ) to see what it does to still trigger this problem. But the underlying Bug needs to be fixed in GnuPG Kleo can only workaround that.