Page MenuHome GnuPG

gnupg 2.3.1 breaks gpgme_op_createkey()
Closed, ResolvedPublic

Description

After upgrading gnupg to version 2.3.1 on our CI for MacOS (via homebrew), the invokation of the GPGME function gpgme_op_createkey fails with error message "General Error".

I was able to reproduce the error in ArchLinux by manually compiling and installing gnupg 2.3.1 on the vm (Arch still uses 2.2.27-1 in its repo as of now). The problem disappears whenever I switch back to gnupg version 2.2.27.

Attached please find the code to reproduce the problem.

Versions used:

  • gnupg 2.3.1
  • gpgme 1.15.1

We temporarily mitigated the issue by using gnupg 2.2.27 on our build server.

Event Timeline

The problem might be that gpg tries to ask for a passphrase which fails on the CI. Try setting a passphrase callback and setting the pinentry mode to loopback. See https://dev.gnupg.org/source/gpgme/browse/master/tests/run-genkey.c$435.

Thank you for your response! I tried out all variants of gpgme_pinentry_mode_t and implemented a passphrase callback (using gpgme_set_passphrase_cb as suggested). It turns out that the callback is not invoked at all. However, if I switch back to gnupg 2.2.27, the callback is being invoked and the key is being generated (using the passphrase specified by the callback, as expected).

Well, all I can say is that
./run-genkey --loopback "elektra testkey (gen-gpg-testkey)"
creates a key without any problems and without asking for a passphrase. Even, if I add the GPGME_CREATE_NOEXPIRE flag to the call of gpgme_op_createkey. At least, from a terminal.

I'm using gpg and gpgme from master, but they should be close enough to the versions you are using.

run-genkey is working fine in my test environment as well.

The problem was on our side. Removing the flags GPGME_CREATE_SIGN | GPGME_CREATE_ENCR from gpgme_op_createkey fixed the issue for us. All of our builds succeed again.

Thank you very much for guiding me into the right direction!

ikloecker claimed this task.

You are welcome.

I guess the problem with the flags is that gnupg 2.2.27 creates an RSA key by default which can be used for signing and encryption, but gnupg 2.3 creates a key with an ed25519 key as primary key and such a key cannot be used for encryption. Explicitly requesting the creation of an RSA key might have fixed the issue for you as well. But it's better to go with the defaults unless you need a specific algorithm.