Last week:

• configure.ac and VERSION: T3283: done
• gpg/card bug for forcesig: T4177: fixed
• libgpg-error: config.guess, config.sub updated
• gpg-error-config: now, it can be arch independent with "auto" mode, ready to be Debian (and other multiarch environment)
  • Many/Most of Alon Bar-Lev's points are now irrelevant
  • Let's see how new gpg-error-config will be used on Debian and others

This week:

• T4158 needs update: UIF command should be only supported when card has it's capability
• card key selection and key selection in general
  • While I see something are requested, but I can't see exactly: T4167: Pinentry prompt is confusing with regards to multiple smartcards when gpg-agent is used as ssh-agent
• Gnuk release with some doc update
• FST-01SZ test case (the procedure to test the board at factory) preparation

Done for libgpg-error.
Will extend to other software.

Applied to master: rE91bcb2c7d824: gpg-error-config: Support "auto", architecture independent script.

It is propably related to decrypting large (single) tar-files. It works flawlessly when renaming the tar-files to another extension before encrypting and afterwards decrypting it again. But as long as it is named xyz.tar Kleopatra crashes. Could it be that untarring causes some "out of memory" failure? I recognized that while decrypting the tar there was no sign that the decryption process would allocate any disk space. There ist just an empty randomly named folder being created upon decryption.

Thanks for taking the time to create this report. It should be fixed in Gpg4win-3.1.4 please try out that version. :-)

Related, the tab formatting (mixed first one tab and then space), as in lines 131 to 137 of src/icons.c _really_ causes headaches.

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

Almost the same bug also happens with pinentry-tty.

Sorry, pressed enter too early. the bug report is complete so far. I guess it is a lot of work to reproduce, so I'd try to be very responsive instead.

Thanks for the reporting templates; would mind to fill in some bug details?

Here goes.

With Gpg4win 3.1.4 and the two blocking options, searching for any name in Inbox, entering more than 2 letters will crash Outlook 100%.

there should be clearer labelling of smartcards so that users can tell them apart more easily

I did a small update to D467: Enable dynamically defining pkg_config_libdir for multiarch. The name is changed to "auto" (was: "unknown"). It now support other cases where CC is not a kind of gcc.

Support CC is the one of clang.

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

Dear aheinecke,

Hi Adam,

My pic didn't appear inline, so I'll add it again as attachment

maybe a setting is also involved. marking the mail in the Junk folder gives:

There was a report about this in the past T3956
I tried it out then with a junk folder and for me it worked so I closed the issue as a duplicate of the general moving mail problem.

I broke it a day before the release and didn't notice.
Since f34cd2782bc0cd6f359c14de4d4a889ec4e49a6e it accidentally logs all string allocations if one of DEBUG_TRACE DEBUG_MEMORY or DEBUG_DATA is set. The intention was that it should log when all three are set.

FWIW, you should better not change the build-aux/ files becuase they are supposed to be updated from libgpg-error.

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

@werner, I think that the scope is different. The bug reporters' claim were basically "GnuPG's cross building is different (for them), why?". They didn't claim GnuPG were unable to be cross-build.

That is a different python binding than what we provide with gpgme. Our gpgme based binding is called "gpg" and was formerly known as "pyme". I strongly suggest to install gpgme and not to use pip because the "gpg" module over there has not been updated for quite some time.

from pip i used command
pip install gnupg

From where did you go that "python package gnupg==2.3.1" ?
Sorry, I can see what kind of Python code this is. It is not part of GnuPG, though.

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

Frankly, I still do not understand the problems with cross-compiling. Since 2014 we support SYSROOT and the respective foo-config script is installed as $SYSROOT/bin/foo-config. This guarantees that a matching config script is used and because it is a script it works on all platforms from which we are cross-building. It is also fine to install that very script in the bin dir of the (target) host; it will work there as long as host is a Unix system. So it does not matter whether it is a plain text file (a la pgk-config) or a POSIX script. The only important thing is to really install the foo-config at SYSROOOT/bin - make install does it.

Hi Andre,