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.

I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

it is the decision of the user to use such a certificate.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

Thanks for your additional suggestion. I pushed the change.

For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.

For BSD Make issue, please try:

Ah, yes. Will do. Thank you for reminder.

For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure

Using BSD make on git head of gpgme, I see

Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.

Fixed in rM37d62e9d0f68: core: Implement _gpgme_getenv for NetBSD..

Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

1.10.0 released

I'd really like to understand what is going on. Thus keeping the report open.

Resolved with gpg4win-3.0.2

Pushed rM7b5182f28893

Frankly, I doubt that this belongs into gpgme.

Andre can you please apply this?

Prio low, as I noticed that Kleopatra already had some code in there to merge a secret with a public key in a keylisting. This can be used for me.

Normal priority as this should be looked into but is not dramatic.

In T3056#95172, @wiz wrote:

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

Testing it without patches does not work because:

get-env.c:57:2: error: #error Use of getenv_r not implemented.
 #error Use of getenv_r not implemented.

There are multiple problems. I fixed one Makefile portability issue today.

Fixed in 2.2.3, too. Closing.

data.gpg is fine and data2.gpg shows this wired behaviour. The difference is at the end of file last two bytes : 0040 vs. 0a40.
Initally i took data.gpg to create the base64 encoded version for the message.

I tried to reproduce this simply by creating an encrypted file with gpgme/test/run-encrypt and then running kleopatra on it "kleopatra /tmp/foo.gpg" kleopatra prints in debug output the decrypt / verify result from GpgMEpp. No error for me.

Shall we close this?

Add the tag of npth (forgotten).

Done for libassuan