For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

Thanks for the report. Indeed I've overlooked this.

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.

See T3505 for more in depth coverage of this issue. Essentially this is a duplicate under a slightly altered POV.

Confirmed that this is indeed fixed and made the (rather minor) change to the HOWTO that was needed. No changes were needed for the example script (decrypt-file.py).

This has now been tested on a 32-bit Gentoo VM and it behaves as expected with 32-bit system detection and creating keys with pre-2038 expirations working.

Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.

I'll deploy one on AWS somewhere briefly once I've replaced a certain external keyboard, there will almost certainly be an existing image of some Linux distro in the AWS marketplace and I'd be very surprised if it took more than an hour or two of compute time to confirm.

One more semantic question about how folks think Context.decrypt(verify=True) should work: if the decrypted thing has no signature at all, should the function succeed without throwing an exception? it currently does, but the returned verify_result has its signatures member set to the empty list.

Ooh, nice catch @dkg, I just stepped through each of your changes and it all looks good. I'll tweak the relevant sections of the HOWTO dealing with this in the next few days (I need to replace a keyboard here before properly diving back in) and then close this case once done.

since @aheinecke merged my changes, i think this bug is now resolved. I'll let @BenM close it though :)

@aheinecke thanks for the merge of my other branch! sadly, that branch does *not* address this issue yet. It doesn't even test for it. :( I can work on trying to fix it (and test it) if there's a consensus that we want this particular change in behavior.

Is this fixed now?

Ben is not even subscribed to this issue.
With the volatility of gpgme-python I think that this can easily be merged. I did a quick review and it looked good to me.

Needs to be merged. (Note that Phabricator does not show the branch in the tooltip for commit ids.)

note that the branch also updates the test suite to make sure the verify=False case is tested.

I've just pushed a branch dkg/fix-T4271 , currently at ac8d7238dbf165950c9844e5cb41da8eb4d37bc0 that resolves this problem.

Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.

Just to stress it; I am in favor of allowing builds using other compilers. We allow this on Unix and so we should allow this on Windows as well. We should remember to use different DLL names to make it explicit that a certain DLL is targetting a specific ABI.

Another build systems does not solve your problem. If you want to support another toolchain, that is fine. But it can as well be done with the current build system. it is a matter of adding a new platform triplet to make sure we are not linking against different libc versions. In fact we can build all our code on a wide range of platforms with very different compilers, so supporting MSVC won't be a problem. Mixing them is a bad idea as can be shown by the usual cross-runtime malloc/free problems.

Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(

I give this high priority. This blocks for years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC (you can say that this is bad, but it is a fact of life). As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.

I think that is something I want to grapple with next year. The maintainer of KDE 4 windows noted that they currently rely on the patches from:

Regression introduced with 1.12.0.

please add a unit to the test suite to make sure something like this doesn't happen in the future!

i'd be happy to help you set up your own x86 32-bit guest VM for testing
if you like, even if you're running on x86_64 hardware. they're cheap
and easy to run, and have a delightfully small memory footprint :P just
let me know!

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.

I consider this bug to be solved.

MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.

While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.

Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.

The explicit check for a valid FD (in select) I mentioned above is commit 8173c4f1f8a145c4b1d454f6f05e26950e23d675

I'm currently looking at the CloseHandle in _gpgme_io_close:

Btw I've checked that the errors are the same in T4111 and this:

Fixed it myself as I confirmed the leak with Dr. Memory.

I've seen now four crashes in _gpgme_io_spawn. I've added tracing that shows that the CreateProcess itself is crashing. I do not see how this is possible. I'm printing the command line and the program name in debug output and both look fine.
The command line is also mutable.

I'm also seeing hangs. Sometimes with gpgsm running. Sometimes without it running.

Nesting the op_genkey() calls inside try/except statements with the exceptions being caught as "oops" and otherwise "oops" being set to None provides a means of checking whether the 2099 expiration is a problem and 2037 is not.

Well, I guess this answers my question in T4192 regarding why op_genkey was in use.

Interesting, I'll look into it, but is there a reason for using op_genkey instead of create_key (optionally with create_subkey and/or key_add_uid)? The latter should be easier and more pythonic.

In T3354#118876, @justus wrote:

This should already be possible, iirc the Arch Linux maintainer patched
it in. I believe there is a 'prepare' target that takes care of all the
preparations (duh), and then you can build for every Python version by
executing the Python build system with the Python version of your choice.

@werner, thanks for rMff6ff616aea6 -- i've backported it to debian's packaging and it lets us cleanly build against all installed versions of python.

Here goes.

That is up to @BenM

The default mode of the tool is to use the Native Messaging protocol which prefixes requests and responses with a 32 bit native endian length header. It is the default due to the way browsers call native messaging programs. If you want to use it in a different way, use the option --single or --interactive.

That it will not be a problem on that or near that date but already now because some use expiration times of 20 years.

what does "not only on Jan 19, 2038" mean here?

the error i'd seen earlier after reverting the change was an error due to running t-callbacks.py on its own, without the rest of the test suite framework. running it within the test suite framework (with the change reverted), it passes without a problem. I've uploaded 1.12.0-4 to debian with a patch to t-callbacks.py. I can apply it upstream, if you want me to.

See T4195 for the general problem

I have not looked at the new error but the year 2099 is clearly a y2k38 problem. gpg has some precautions but I have not checked the key generation code. The gpgme interface uses a signed long for the expiration time, although that it parses the dates received from gpg as an unsigned long. Right now, I am not sure why we did this because an unsigned long would just work. Maybe we can change or enhance the interface. But in any case this is a general problem and not specific to this bug.

@BenM thinks that swig is still the best option. Actually this case helped to find a bug in gpgme. See my next commit.

The error might have to do with rM46da79e3de99a7b65748994921d6aab73b9974e7 which looks like it might run afoul of 32-bit time_t (Y2K38 problem?).

here's me running just the specific test:

If the swig interface isn't robust, can we replace it with something that will be more robust? Or do we need to wrap it with hand-crafted error checks that describe the API's constraints? It's pretty bad form to segfault python.

When parms is malformed but not NULL, then the error appears to be a bug in the python bindings in _wrap_gpgme_release. maybe something is going wrong because of the "cannot allocate memory" error? in particular:

That swig based interface is not really robust and it can't be because it does not known about API requirements. I bet there are other places where mandatory parameters are not checked.

To deal with passing None correctly, it looks to me like the problem is inside get_parameter() in src/genkey.c -- there ought to be a check for parms being NULL, and then returning either GPG_ERR_INV_VALUE or something else. otherwise, the segfault happens inside strstr.

It the first error (first param = None) is a segfault in versions 1.11.1-2 (debian unstable i386) and 1.8.0-3+b2 (debian stretch amd64).

Is this new in gpgme 1.12 or might it also be in older versions?