In the meantime, I upgraded my Fedora installation so I won't be able to reproduce in the same circumstances. I suggest we close the issue for now. I will reopen if I manage to reproduce.

I tried this with the current 2.2 branch and master and was not able to replicate it. The stubs are all deleted as expected. I also checked the commit log since 2.2.6 and didn't found anything which indicated that such a bug was fixed.

See rG26bce2f01d2029ea2b8a8dbbe36118e3c83c5cba for a description of the problem and its fix.
Thanks for reporting.

Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.

Thanks. I added all standard names to that list.

I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?

With recent versions of gpg you will now get Bad Data etc. This is implemented by giving an ERROR status line a higher precedence than the NO_SECKEY status.

BTW, you now need to use --rfc2440 to create a non-mdc message for testing.

Better?

Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:

Please add

Please dee the commit for a description of this fix.

Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.

That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?

Yeah, that's not good enough. You also need to check if literals_seen is 0 before BEGIN_DECRYPTION to catch the case where the plaintext packet comes before the encrypted packet. See https://github.com/das-labor/neopg/commit/30623bcd436a35125f21fe6f29272a5fa7212d3f

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

Thanks. Yes, I think that's it. Here's a video just in case.

Ok You could notice it because if the year changes there was no "blue" selected date in the current page.

Had a bit trouble reproducing it. It worked for me.

It's nice. Although for now I've only added a message in the legacy_cipher_nomdc case:

I've noticed during testing that GpgOL would not send valid PGP/Inline signed only messages and also failed to verify such messages itself when special characters were in the mix.

Oops. The commits added here belong to T3975