Thank you very much for addressing this so quickly. I agree that corrupt data needs no further details here.

Thanks. Indeed we should have better error codes. However, passing all error codes from the backend to the user is not useful.

I am using Debian 9 with the packaged versions. For gnupg this is 2.1.18.

@aheinlein we need to know the gnupg version you are using with GPGME.

I've since tried neomutt-20170707 which includes stbuehler's patch, but I see the same error cases as before.

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.

Thanks, LD_LIBRARY_PATH solved the problem

This is a bug tracker, not a support forum.

Hi, I found a workaround for neomutt (see https://github.com/neomutt/neomutt/pull/662).

Refile if problems with current versions.

GnuPG needs to report compliance when decrypting symmetrically encrypted packet.

Implemented in gpg, gpgsm, and gpgme with all bindings.

@aheinecke thanks! My apologies for not making that clear in the initial report.

*facepalm* Ooops. I see. Thanks for the report. I'll fix it.

@aheinecke Yes, the issue is with INTERFACE_LINK_LIBRARIES not IMPORTED_LOCATION.

Uhm I thought this was fixed with 2e661b9e1a9b50656a5c9646d7444a98477010c1 that should have been part of GPGME-1.9.0 are you sure that you are not seeing this with an older version?

Yes.

Reading that PDF I guess we need the same functionality in gpgsm too, right?

In T3059#98047, @werner wrote:

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope.

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope. Even key management is out of scope. OTOH, certain algorithms are simply not allowed. This means we can't use SHA-1 except for specified and approved usages (in our case OpenPGP fingerprints).

Yes. mark them as non-compliant.

In T3059#98040, @aheinecke wrote:

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Sounds exactly right to me.

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

In T3059#98015, @werner wrote:

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms.

See kerckhoffs:~wk/ST-Gpg4VSNfD-v0.6.pdf - eventually this will be published but right now we don't have clearance from the BSI to do that.

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms. For cipher algorithm, we will only allow AES* and digest SHA-2-*. Other details are in a document we have in an project internal wiki - I'll send you a copy.

Ok, good to know. However, I still need more information about what it means to comply with CO_DE_VS. Any pointers?

I thought about this but in the end it is unlikely that we will see request for other protection profiles. Thus I did spend a single bit on the German thing. Further, it is quite possible that a message matches several profiles and than bit fields come really handy. For the very limited circle of users a dedicated sub system for such things would be overkill.

The GPGME API uses field names like 'is_de_vs', but isn't that short-sighted because we hardcode names of compliance modes into the API? Also, 'vs' seems to match both 'VERSCHLUSSSACHE – VERTRAULICH' and 'VERSCHLUSSSACHE – NUR FÜR DEN DIENSTGEBRAUCH'.

I need more information about what it means to comply with CO_DE_VS. Any pointers?

https://build.opensuse.org/package/live_build_log/openSUSE:Leap:42.3:Staging:A:DVD/gpgme/standard/x86_64 looks good. Closing this task.

I've accidentally pushed this commit. But I'm very sure it's Ok anyway and pretty trivial. And it's been over a month to object. I really need this patch to get keygen working with default_pubkey_algo in kleopatra. It was also included in the last gpg4win betas.

Well, this will be a different thing and more related to the to-be-implemented key origin feature.
I would thus suggest to open a new task for this.

I think we are talking "aneinander vorbei". AFAIK we agreed (on the Osnabrück meeting) that we will cater to this usecase: Multiple different keyrings for some operations. Or "curated" keyring. Through GPGK and so we will have some API (key probably not a keyring for a context) like this in GPGME at some point in the next years. This is why I think this issue might be kept open to say: Yes we see the usecase but we will not solve it by exposing, what you call a hack, through GPGME. But we will solve it at some point with a better solution.

Back to you original problem: What you are trying to do is a hack to work around properties of GnuPG. Namely, that GnuPG stores its state in a _directory_ and you are modifying parts of this state (e.g. pubring.gpg). This is why GPGME allows you to switch to another directory but obviously does not allow you to modify parts of a directory (i.e. the state).

FWIW I strongly disagree with the sentiment that GPGME should be a "dumbed down" "Easy" GnuPG API. It should be GnuPG made stable -> A stable and reliable C API for the Free Software OpenPGP implementation GnuPG. But this is off topic. SCNR. It's much easier just to use process calls in many cases but I understand why this should not be done and leads to maintenance problems / bugs.

As discussed: The proper solution for this is GPGK, a Pubkey deaemon for GnuPG that would cater to audited / monitored keyrings. The usecase has not gone away and from my talks with people in the community and my general experience it is not "special" and definitely not "very special". It's important for Software Developers using GPGME that want to have keyrings for their Software Seperate from the general GnuPG user setup.

GPGME is about making GPG easy and not to cover very special use cases. I'll thus close this bug.

texinfo.texi has been source copied from the GNU repo and thus the typos are probably already fixed upstream. Anyway, I agree to fix them here; in particular because there are some discussion in the GNU project to move away from texinfo.

I accepted the patch so this ticket should have been resolved. Sorry.

Ping. Is this patch ok? I'm pretty sure it is and I've included it in Gpg4win but before I can push the default_pubkey_algo respecting change to Kleopatra I need this to work in GPGME.

I've updated to gpgme-1.8.0 and tried again.
I have one mail that I'll call "bad" which gives me in mutt:

This works fine with GPGME 1.9.0 and master.

Patch now fixes the problem in gpgme

I guess I should do this.

Ah right, that is bad...

I just tried this, but this doesn't disable the detection, and if that fails, the configure script stops:

checking for swig... /usr/pkg/bin/swig
checking for a Python interpreter with version >= 2.7... python2.7
checking for python2.7... /usr/pkg/bin/python2.7
checking for python2.7 version... 2.7
checking for python2.7 platform... netbsd7
checking for python2.7 script directory... ${prefix}/lib/python2.7/site-packages
checking for python2.7 extension module directory... ${exec_prefix}/lib/python2.7/site-packages
checking for python2.7... (cached) /usr/pkg/bin/python2.7
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/pkg/include/python2.7
checking for Python library path... -L/usr/pkg/lib -lpython2.7
checking for Python site-packages path... /usr/pkg/lib/python2.7/site-packages
checking python extra libraries... -lutil -lm
checking python extra linking flags... -Wl,--export-dynamic
checking consistency of all components of python development environment... no
configure: WARNING:
  Could not link test program to Python. Maybe the main Python library has been
  installed in some non-standard library path. If so, pass it to configure,
  via the LDFLAGS environment variable.
  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
  ============================================================================
   You probably have to install the development version of the Python package
   for your distribution.  The exact name of this package varies among them.
  ============================================================================

Sure there is. Do ../configure --enable-languages= to build no bindings at all.

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/