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

There was a second person asking for a list-packets feature to verify if a file is encrypted correctly at gnupg-devel.

Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py

Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.

The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.

(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)

Thank you very much! This is working quite well now.

I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.

I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.

I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.

OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.

No, I don't have a smartcard. Perhaps it misdetects one?

For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.