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

Here goes.

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

That is up to @BenM

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.

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:

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.

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.

Hi Andre,

I think it has something to do with the number of files. Just encrypting / decrypting a 10GB random data file did not show a problem.

Hi Andre,
thanks for the fast feedback. I will wait for the 3.1.4 Release then and test it afterwards. If it still occurs i will update this thread. Thanks for your help!
All the best
Dorian

Hi Andre,
thanks for the feedback, will try this asap when i have the chance to get on the laptop of my co-worker. Will update you afterwards. Thanks for the help!
All the best
Dorian

Thanks for the report. Prio High as this is data loss. I won't stop the 3.1.4 release which is currently in progress though as this issue does not appear to be a regression.

Your best bet is to try it on the command line to see if that provides some more useful output:

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?

I decided today to install the beta version and give it a try, because the final version is not yet released. I still facing major problems, see attachment. The mail will not be delivered, but Outlook does not crash as before.

I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.

Done for libgcrypt, finally.

ntbtls adopts the way from the beginning.

Just commited. Thanks.

The current version is 0.9.10 and the reported 0.9.5 is 4 years old. We also received no more info.

Thanks for the report I'll look into it. Won't make it into the next release though as we are currently very close to the release.

I could reproduce it at first, but when trying to make a screenshot clip
from that, I couldn't reproduce it any more, no matter what. It's either
gone (mail server update?) or needs a very specific sequence of events
that is quite unlikely.

@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

Please check your ld.so (dynamic linker) setting (/etc/ld.so.conf and/or LD_LIBRARY_PATH).

Please put

Done for gpgme.

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

The fix was not fully correct because it considered a back signature's usage tool.

Hi, Has anyone found a reason why that happens. I run into the same behavior on my Windows 10 1803 computer. I have Gpg4win version 3.1.3 freshly installed and dirmngr hangs. Thanks and best regards, Peter

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?

Thanks for your analysis and the report. The good news is that we had this already reported and have fixed it.

gpg: keydb_search failed: Provided object is too short

So these are the results for gpg -K:

Thank you for your detailed report. Seems like something strange is broken on your system and our error handling does not properly cover that.

After several experiments with attachment flags to get the same behavior outlook does for unsigned mails I could not find a way to set both the content-id and cause the attachment not to be hidden.

The reason for this appears to be the "Content-ID", this is usually set for embedded attachments like images and not for attachments like PDF's.
This leads to the attachment being hidden, e.g. if you have embedded images you do not want them to show up in the list of attachments.

Turns out that that was not the problem.

I ran gpgconf --kill gpg-agent and then the suggested command for i in {1..10}; do gpg -v --no-tty --verbose -o - encrypted.gpg 2>mylog.$i > /dev/null & done. (I was already running with --verbose, does -v add something else?)

In the interests of completeness I also tried it on a much larger file (1GB) which was both signed and encrypted. I also set the decryption to show the session key just to confirm it was decrypting since the plaintext was being sent to /dev/null.

I am unable to replicate this on OS X 10.9 Mavericks.

Running with -v would really be helpful.

This was a regression from 59e8a7ee3bcd16275091c9535626e49fc2a6c4af where a performance improvement to cache an object caused this problem.

Ah wait, I just remembered T4142. Maybe that is related. I'll try to reproduce that one first.