Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960

Not to worry, we've all been pretty busy of late.

Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:

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.

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?

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).

[We do things in the public unless explicitly requested by a bug reporter writing to security.]

Maybe the off_t mess comes from following line

The gpgme c api already had a convenience function gpgme_data_rewind to do data.seek (0, SEEK_SET); As this is by far the most common seek operation. KMymoney also only uses such seeks.

In T3996#114721, @aheinecke wrote:

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

So what the error tells us is that "off_t" is defined as long in the declaration but as something else in the definition.

But how can that be? data.cpp includes the data.h header so they both should have the same definition of off_t.

The only thing I could imagine is that something which is included in the cpp but not in the header undef's off_t and defines it to something else.

Or more likely that the archive was compiled with a different definition of off_t then what is included in the headers when kmymoney is built.

Are you using the same mingw version as the buildchain which compiles the gpgme binary?

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

You are not cross-compiling. This is not suggested and I don't have the environment to replicate this. Maybe @aheinecke can help.

Have to test it but I think its resolved. The registry path handling is now similar to that of GpgOL and GpgEX.

In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

Webhelp version of the Python bindings HOWTO is currently available here:

As a work-around for this bug I've ported the HOWTO from org-mode to DITA XML and will generate a webhelp-responsive (i.e. searchable) version to put on another website (an Amazon S3 bucket since it will be reliable and cheap) in the interim.

Org-Mode was updated to today's release and further testing was conducted.

It seems that Debian does not install te required libgpg-error correctl.

I downloaded it and I' m using it.
Nice feature the "notepad".... easier for encrypt/sign.

The latest Version of Kleopatra has a "Notepad" View that should do what you want. E.g. If you decrypt something in there it preselects the keys the message was encrypted to when you encrypt it again.

In T3963#114101, @aheinecke wrote:

OOooh yeee.
Ok. Didn't know how bad gpg4usb really is.
I looked into it. Gpg4usb distributes their own binary GPGME version https://github.com/gpg4usb/gpg4usb/tree/master/linbuild/lib I don't even know which version that is. They are in violation of the GPL as they don't offer the source code of that GPGME version.

So, don't use it please what they do is horrible from a security standpoint. Try using Kleopatra (which I personally maintain). And if it does not work for your use case please let us know what your use case is and we can try to make it better for you. :-)

But indeed for gpg4usb you can't expect help here. They are very likely shipping a horribly outdated version with bugs that have since been fixed.

I 'll try GPA and Kleopatra, I hope will do the same tasks.
thanks anyway.

I suspect gpg4usb is a dead project anyway. I've been on their mailing list for a while and according to my records the last post from the pseudonymous author(s) is from October, 2016. I'm not sure how much of that GPL breach is intentional or just a result of web services going offline and not being restored.

The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).

It seems to be 1.1.6 from 2010 or so. They use gpg 1.4.20 which misses a critical security fix.

OOooh yeee.
Ok. Didn't know how bad gpg4usb really is.
I looked into it. Gpg4usb distributes their own binary GPGME version https://github.com/gpg4usb/gpg4usb/tree/master/linbuild/lib I don't even know which version that is. They are in violation of the GPL as they don't offer the source code of that GPGME version.

I'll volunteer to look into it. IMO "Invalid Crypto Engine" points definitely to a GPGME bug and I want to know whats going on there.

@dcialdella Well as you are here already you can open one here. Alternatively I would have thought Ubuntu's Launchpad.

@aheinecke thanks for the post.
When you said "open a new issue" is create here or in Ubuntu forums a new issue ?
I'll do. when ?
I imagine ni some weeks will be solved but I use the tool everyday for secure text.

@dcialdella I've checked the Ubuntu Patches, they don't include the patch that caused the problem for GpgOL in this issue. Please report your problem either to Ubuntu or open a new issue, ideally with some instructions how to reproduce your problem.

I've just checked the current build to the previous one (even when I get rid of the build directories, I keep a copy of the config.log since you never know when it might come in handy).

FYI: this most recent update broke builds on OS X 10.9 for Qt, but everything else is fine.

The highest priority I see here is for T3953 which I think is a bug that might result in a good signature shown for an expired, but otherwise valid and trusted certificate.

gpg 2.2.4-1ubunt amd64 GNU Privacy Guard -- minimalist p

It's possible that was one of the upstream patches they decided to include.

@dcialdella Do you have a "non standard" GnuPG / GPGME installed? What are the versions?

I have the same issue with Xubuntu 18.04 lts, and GNUPG.
./start_linux_64bit
[Error] Source: GPGME String: "Invalid crypto engine"
[Error] Source: GPGME String: "Invalid crypto engine"
[Error] Source: GPGME String: "Invalid crypto engine"

Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).

The last change to the python installer was, IIRC, one I discussed with Justus off-list around the middle of, um, last year? Maybe the year before?

@aheinecke maybe recheck with GNUPG 2.2.6 or 2.2.7.

I'm using the kdepim-docker for tests, that is based on KDE Neon, that is based on Ubuntu xenial (16.04), so the version for GnuPG2 is 2.1.11-6ubuntu2. Good to know, that the GnuPG version also matters for this stuff.

I can't reproduce this with GnuPG 2.2.6 or 2.2.7 beta and GPGME 1.11.0 . There I correctly get User Canceled for OpenPGP but "No Secret Key" for S/MIME, also using GpgME++.

Not to mention making sure we test for a time after the end of the old 32-bit clock.

Also confirming the workaround. Not sure whether it would have done me any justice to counter-sign the key after accepting it locally, since I only verified it against their web page. The web page is hard to find with a Google search, since Google does not turn the unspaced hexadecimal fingerprint into something that matches the space-every-four-digits format used on their PGP/GPG instruction page. Searching for "Facebook PGP key" works, though.

The commit mentioned fixes the problem.

I can confirm the workaround. After importing the key from Facebook everything works as expected!
Thank you very much!

Thank you very much. It helped. I can reproduce the problem now.

Same here with Mails from Facebook, here's the log

"Invalid crypto engine" Means that there is some internal error in the signature verification / decryption.

Right now building the release.

My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

Just checked. This does not seem to be a regression.

Weel, you GnUPG version is actualluy the lates. Unfortunately I tested with a beta version. Let's wait a day to see whether there is more fallout and if not I will do a 1.11.1

Look like you are using an older GnuPG version and thus the test fails. I need to tweak the test.

Are you asking for a way to --refresh-keys via GPGME? IF so shall that be a syncronous thing or just a trigger. Note that we the last update time is already part of gpgme_key_t and can thus be used to check whether a trigger worked.
Anyway this will be a larger change and may need gpg support.

Ben: We need to use a faked system time thing to make those tests more stable.

With the recpstring feature in 1.11 this is now possible because the args are passed verbatim to gpg.

Implemented in gpgme 1.11.0 if gpg >= 2.1.23 is used.

We never tried to build gpgme with MSYS2 and I would also say this is not supported. A wild guess is that this mixes platform specific code.