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

[Jeffrey Stedfast]

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 gnupg.org> wrote:

    On Mon, 27 Feb 2017 15:20, jestedfa at microsoft.com 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
    access.


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
    verbose
    --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
    verbose
    --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: https://gist.github.com/jstedfast/38ab7fe65f0c769ba31bd5a807e2f374

    
    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: https://gist.github.com/jstedfast/c9fa718ef524a73de02daacc142beccc


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,

Jeff