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?

"dkg (Daniel Kahn Gillmor)" <noreply@dev.gnupg.org> writes:

what's the status on this? i'd love to be able to build binaries for
both python3.6 and 3.7 for debian. as it stands right now, the
python3.7 continuous integration test for debian is failing
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/gpgme1.0/1158040/log.gz.

That is a strange failure. I don't see how that can happen without a legitimate bug.

what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.

It seems to be a cpp problem. Andre, would you mind to take this bug?

@werner And perhaps it's worth mentioning that in my case it is gpg2 --version; gpg is 1.4.23. I have no idea whether that might play any role.

@werner Hi, the version output is as follows:

Thanks for the report. I would also like to see what

I moved the location of config.h to a new "conf" subdirectory. This should solve the issue. Thanks for the report.

C++2a will have a <version> header, so some trunk libc++ headers now (indirectly) #include <version>, and on a case-insensitive file-system, when compiling a gpgme source file with "unlucky" -I../../.. switches against such trunk libc++, that can mean that such an #include <version> picks up gpgme's VERSION file.

Sorry, I am not sure whether I understand the problem. Sure we have a file VERSION in the top directory but from where and why is it included? Is that some libc++ includes a file "VERSION.h" and somehow the preprocessor includes the file "VERSION"? IS that specified in a new revision of a standard?

sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.

The background of my earlier comment was that I didn't tested GPGME in this regard.

if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:

Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.

yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.

@dkg does --no-keyring solves the problem for you?

Gpg4win-3.1.3 was released.

This happens only if GPGME_DEBUG is set to 9 which was accidentally set in my environment. So I've lowered the priority.

I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.

I think it's good to close this as "resolved", since many fixes have been done, and I don't have remaining issue.
@wiz Please open another ticket for your next try.

No response so closing as invalid.

What are we going to do with this report? The last comment is 6 months old; can we change from testing to resolved or do we need to wait for a gpgme release?

I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.

Done.

I've updated the README and added example mainifests.
Make dist is also updated I could build the extension and webpack it from the dist package.

Discussion on the #python IRC channel last night with another experienced SWIG developer (of a proprietary and unnamed software project) has provided ass itional evidence supporting the theory that the cause of the problems with getting the bindings to run on Windows systems is indeed directly caused by the fact that Windows users are compiling GPGME and the bindings with a different compiler and runtime than those used to compile whichever version of Python they have obtained from elsewhere.

Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise

Actually i have now more debug output and i think i found the issue

I close this for now, this seems a problem of the mingw packages in msys2

Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.

Or with both packages installed, could i maybe debug somehow where it searches?

BenM, msys2 uses pacman as packagemanager, all packages are build from source

Alternatively, if they wish to keep using the Python installer from python.org then they would need to drop MSys2 in favour of the same version of Microsoft Visual Studio used to compile the that specific version of Python with and use it to compile every part of the GnuPG stack, up to and including GPGME.

If that is indeed the case and the theory regarding runtime conflicts, currently under investigation in T3505 and T4086, also proves to be true; then MSys2 users and developers will need to cease using the precompiled versions of Python available from python.org and compile their own version of Python copy with MSys2.

Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.

Patch applied. Thanks.

I do not see the harm in this patch and it seems useful. Indeed it seems better then making a directory in tmp as this might create regressions for others.

This question and some of the answers to it on StackOverflow indicate some of the difficulties in getting SWIG generated Python modules to install at all. Essentially, though the easiest method currently available without extensive customisation of the setup.py file which would need to be done for both Python 2.7 and Python 3.x is to run /path/to/specific/pythonX.Y setup.py build and then follow that with /path/to/specific/pythonX.Y setup.py install and then follow that with renaming lang/python/build to a relevant directory and/or path name which indicates which version of python was used and the location or path it is in.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

While performing some initial investigation regarding observed discrepancies between compiling GPGME directly and the subsequent SWIG static object for T4086, confirmed the relative ease by which multiple installations would be achievable if performed as a post-build process. This would have the added advantage of being more readily customisable by package maintainers downstream and not just for Debian, it could be made to work more easily with other distributions or other posix systems too.

Since first observing this … annoyance … the following updates have been made: Emacs has been upgraded to version 26.1, Org-Mode has been updated multiple times, including significant changes to Babel and the XHTML export, python-mode has been updated, multiple variations on the source blocks have been attempted, the document has had any and all tabs stripped out and replaced, plus each code block has been refactored and re-entered multiple times.

Well, green is a shortcut on how to display the status of the signature. It came from the green frame KMail printed and it soley used to rely on that information. The idea was that gpgme tells you what it considers to be a good signature. Opinions and trust models meanwhile changed and thus we indeed need to update gpgme's suggestion.

My idea here is to have a discussed reference how the GnuPG community thinks a signature might be counted. Taking the discussions from our AutomatedEncryption stuff into account etc.
I would then like to extend gpg-error with the according strings / status codes.