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.

To attach a file use the cloud-with-arrow icon in the edit toolbox.

1.11 features a set of extended encryption functions which may optionally take a string as key specifications. In contrast to the array of key objects this string is a linefeed delimited list of key specifications which are passed verbatim to gpg. For OpenPGP a keyword feature is supported. For example the string

A reason we did not touch it in the past is that Ideally we don't want users to have to mess with refresh keys but would rather have this done automatically in the background by dirmngr.

This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.

A work-around is now available for this in Python in the GPGME source. The relative path from the top of the GPGME source directory is here lang/python/examples/howto/groups.py. Like all the other scripts in the same directory, it also appears in the GPGME Python Bindings HOWTO, under the Miscellaneous heading near the end.

Fix was released with GPGME 1.10.0