Problems with GPGME returning "Not Implemented" or "Configuration error"

Jeffrey Stedfast jestedfa at
Wed Mar 8 00:57:37 CET 2017

Gah I hate Outlook which makes replying inline impossible :\

Outlook will indent but not add “> “ to quoted lines, so be aware of that as you read this email (

On 3/6/17, 9:41 AM, "Werner Koch" <wk at> wrote:

    On Mon, 27 Feb 2017 15:20, jestedfa at said:
    > I'm working on re-implementing GMime to use libgpgme (1.8.0 on Fedora
    > 25) instead of using my own custom logic for fork()ing/exec()ing gpg &
    Great, we like the use of the GPGME API.  I guess GMime is not used by
    Evolution ;-)

Yea, I haven’t been involved in Evolution development in ~10+ years at this point… I think Evolution uses libNSS (Mozilla libs) for S/MIME, but for GMime, I’d like to use gpgsm instead.

    Which GnuPG and GPGME versions are you using?

I’m using gnupg 2.1.13 and gpgme 1.8.0

    > For some reason, gpgme_op_sign() is returning GPG_ERR_NOT_IMPLEMENTED
    That can have several reasons.  I can't tell without having a log.

I’ll see what I can do about getting you that log…

    > while gpgme_op_encrypt() is returning "Configuration error".
    Does it work on the command line?  I would suggested to put
    "disable-crl-checks" into gpgsm.conf or even "disable-dirmngr".  If that
    works you need, you need to make sure that CRLs and intermediate
    certificates can be downloaded.  That may require to configure LDAP

Adding “disable-crl-checks” to my gpgsm.conf fixed encryption.

That leaves signing and decrypting as both failing with “Not Implemented”.

It’s an improvement!

    >>From what I can deduce by scouring the web for information, it seems
    >>like NOT_IMPLEMENTED should never get returned unless I am using
    >>options that just haven't been implemented yet but that doesn't seem
    >>like it should be the case since I don't think I'm doing anything out
    >>of the ordinary.
    Reseting the context may also be a cause for this.

Sadly, resetting the context did not help (

    > For encrypting, I am getting "Configuration error" which I'm also
    > confused about because I don't know what configuration options could
    > be causing this.
    Probably dirmngr.conf.  See above.  What you should do is to enable
    debugging:  If you are using gnupg 2.1 you should put
    --8<---------------cut here---------------start------------->8---
    log-file socket://
    debug ipc
    --8<---------------cut here---------------end--------------->8---
    into {gpg-agent,gpgsm,dirmngr}.conf .  With older versions use have to
    use this (also work with 2.1, though):
    --8<---------------cut here---------------start------------->8---
    log-file socket:///home/USER/.gnupg/S.log
    debug 1024
    --8<---------------cut here---------------end--------------->8---
    then fire up an xterm and run
      watchgnupg --time-only --force ~/.gnupg/S.log

You can see this log here:

    and you see in real time what's going on at the gnupg level.
    To debug run your program using
      GPGME_DEBUG=4:/tmp/gpgme.h: ./testpg.
    gpgme.log gives a pretty detailed listing.  Feel free to forward it to
    me.  If you use a level 7 you will get a complete I/O listing.

That’s really useful, thanks!

You can see the gpgme log here:

I spotted the fact that I was (incorrectly) using gpgme_op_decrypt_verify() when I think I should be using gpgme_op_decrypt(), so I fixed that but I still get “Not Implemented”.

I added a comment to the end of that gist to provide the new snippet that gpgme.log contained after the “fix”.

    > All I can think of is that perhaps there is some leftover state from gpgme_op_import() or gpgme_op_export_ext() that is breaking the gpgme_op_sign() when run at a later point?
    Possible.  I don't think we have good tests for this.

Thanks so much for your help,


More information about the Gnupg-users mailing list