Fixed in 977fc5f0e.

I just tried on an up to date fedora 26 system, and could not reproduce this.

I'm sorry; given the original error message

[-- Error: decryption failed: Invalid value passed to IPC --]

I thought it was the same problem I was having.

Well, at least this works without changing the environment:

The problems I recall were about linking the C library gpgme against MSVC compiled other binaries.

I recall that we had the same problem back in 2010 and solved it. Please describe the ABI differences.

Could be done by adding "--yes" to the command line. Requires a new version of the gpgme_op_delete functions with a flag "force".

Fixed with https://commits.kde.org/kleopatra/3e08e4d25d34140a1d03e02c7bd9d066120d0baa

Ah no. GpgME is not at fault. Kleopatra just eats the status and only shows system error. Have to fix this in kleopatra.

87703dbb86ac8fd8abd23170f8038ea6e3dbde28 was the offender. It called _gpgme_split_fields on a non fatal decrypt error which resulted in a mangled error passed to verify.

Ah! I can now also reproduce it on Linux, I had two gpgme's installed and the wrong one was picked up. Bisect here I come :-)

Do you have a use case?

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.