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.

Again one of these issues I can't reproduce :-/

I made a large file for testing, but it doesn't matter. There's an arbitrary parallel limit where gpg will crash.

Please check again with a recent upstream release or report to Debian. The release from Debian is pretty old and has a couple of non-standard patches.

updated example sent.

I confirm I have the same problem but, unfortunately, the beta did not help.