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.

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

Done for npth.

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.

Now we have this:

We have two cases:

1. No MDC with a "modern" cipher algo

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

Thank you for pointing this out.

Following patch fixes the issue.

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

The fix for this was released with Gpg4win-3.1.1. Forgot to update this task.

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:

With recent versions of gpg you will now get Bad Data etc. This is implemented by giving an ERROR status line a higher precedence than the NO_SECKEY status.

Please dee the commit for a description of this fix.

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.

I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.

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

[We do things in the public unless explicitly requested by a bug reporter writing to security.]

Maybe the off_t mess comes from following line

The gpgme c api already had a convenience function gpgme_data_rewind to do data.seek (0, SEEK_SET); As this is by far the most common seek operation. KMymoney also only uses such seeks.

In T3996#114721, @aheinecke wrote:

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

So what the error tells us is that "off_t" is defined as long in the declaration but as something else in the definition.

But how can that be? data.cpp includes the data.h header so they both should have the same definition of off_t.

The only thing I could imagine is that something which is included in the cpp but not in the header undef's off_t and defines it to something else.

Or more likely that the archive was compiled with a different definition of off_t then what is included in the headers when kmymoney is built.

Are you using the same mingw version as the buildchain which compiles the gpgme binary?

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

You are not cross-compiling. This is not suggested and I don't have the environment to replicate this. Maybe @aheinecke can help.

Have to test it but I think its resolved. The registry path handling is now similar to that of GpgOL and GpgEX.

In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

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.

It seems that Debian does not install te required libgpg-error correctl.