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.

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.

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

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.

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.

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.

if that is the case config.{guess,sub} needs to support this and we should be able to handle this the same way as other Unix platforms.

You seem to have reached the wrong page when searching for msys2

Even after running additional tests like converting the file to reStructuredText, fixing any remaining possible errors and then converting back, the result is that org-mode still appears to save the source correctly, but cannot export it in a correct format with babel. Certainly not to XHTML and likely not to any other format either. So that's definitely a bug.

Massive overhaul of the entire document performed in this commit.

Slight addendum: MSYS2 isn't even part of MinGW at all, see the commentary in this bug report. Nor is it a part of Cygwin, but apparently it is a part of a fork of Cygwin.

Not only is this not supported, but I've now confirmed that MSYS2 isn't even supported by its own project and they direct all downloaders to their MinGW-get installer.

Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.

My bad this already exists.

On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:

The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.

Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)

Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960

Not to worry, we've all been pretty busy of late.

Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:

Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

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.

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).

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?

Not to mention making sure we test for a time after the end of the old 32-bit clock.

Ben: We need to use a faked system time thing to make those tests more stable.

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.

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

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 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.

Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.

this is also https://bugs.debian.org/866555

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.

Thanks, LD_LIBRARY_PATH solved the problem

This is a bug tracker, not a support forum.

Fixed in 1e6073ff.

Thanks for testing.

I've made new container and can't repeat the bug. gpgme
components got updated in Fedora.

Ok, there are no significant patches on top of pygpgme. Note that pygpgme is not really
maintained, and that we neither develop nor support pygpgme. But seeing that dnf is important to
Fedora, let's figure this out.

It would be nice if you could try to reproduce the problem without pygpgme though, just to make a
more minimal test case. I see the exception is thrown during some import. This is how I strace
gnupg to see what ioctls it is issuing:

% strace -eioctl g10/gpg --import ../tests/openpgp/samplekeys/ecc-sample-1-pub.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0BA52DF0BAA59D9C: public key "ec_dsa_dh_256 <openpgp@brainhub.org>" imported

• SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=26716, si_uid=1000, si_status=0,

si_utime=0, si_stime=0} ---
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
gpg: Total number processed: 1
gpg: imported: 1
+++ exited with 0 +++

Note that if you try to strace your gpgme-based application, you need to pass '-f' to strace to
follow forks.

I have grepped through gpgme and gnupg, and it looks like gnupg is only doing ioctls to terminals,
so maybe your container setup is doing something funny to terminals. But let's see what the strace
shows.

Here is the info about Fedora patches
https://www.rpmfind.net/linux/RPM/fedora/secondary/devel/rawhide/src/p/pygpgme-0.3-15.fc24.src.html

On Wed, Jul 27, 2016 at 1:24 PM, Justus Winter via BTS
<gnupg@bugs.g10code.com> wrote:

I see that you are using pygpgme, is that correct?If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?

Thanks for the report.

I see that you are using pygpgme, is that correct? If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?

Let's try to figure out which ioctl fails. Could you try to strace this process?