OpenPGP does not authenticate encrypted data. To authenticate data a signature is required.
The MDC feature is what its name says - it detects modifications of the encrypted data but that's all.

It is fine to close this. Reworking the parser is not going to happen anytime soon.

I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.

I added a note to gpg-preset-passphrase in 877a321d011deb3e8501aa9cc5e9f9cd0b19dddf.

Compiler bug. Probably misdetection of aesni support in old AMD processors?

gnupg uses LC_ALL, LC_MESSAGES, LANG and the system default determined with GetThreadLocale() on Windows. Can you please check if you have set any of these environment variables?

Nobody provided a better description, so I am closing here. Of course, we can still add one if somebody wants to improve it.

Because werner says he fixed the memory access, I am closing here. werner, if you want to keep track of the invalid encoding issue with the asn.1 parser, please open a new task with some details. pascal, if you find anything missing, please open new tickets (as you said, it's easier to keep track of issues in separate tickets).

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

The revert was done in 7195b94345b0bb937477dc47fc5ec27fb108a099.

Without more information, we can not act on this.

Without the necessary info, we can not act on this.

@gouttegd thanks for the offer. I will consider adding a variant using clock_gettime. However clock_gettime is not available on all platforms and thus it needs to be ifdef'd. Fotunately there is npth_clock_gettime which has a builtin fallback to gettimeofday. Given that we require nPth in gpg-agent anyway, this seems to be the easiest way. It uses CLOCK_REALTIME

Thank you very much for addressing this so quickly. I agree that corrupt data needs no further details here.

@gouttegd that is a very nice and fair assessment, thanks for taking your time to look into it.

@landro Would you like to do one more round of testing?

I can reproduce the described behavior. I have a 4.11.7 kernel with NO_HZ_IDLE=y and everything works fine, but if I set VIRT_CPU_ACCOUNTING_GEN (all other options remaining unchanged), the agent is stuck in the calibration loop (tested with GnuPG 2.1.21 and current master branch).

The Debian report includes multiple workarounds for the quite unusual setup. So, I am closing here.

Is this even something that we can control? This stuff is usually up to the window manager, and although some accept hints, this is not really well defined. For example, gcry_prompt_set_caller_window accepts a window-id-string and says:

This seems to depend on the window manager. With Fedora 26 and Gnome 3 desktop, a full grab is not allowed anymore, and there is no close button on the modal dialog. With i3 and pinentry-gtk-2, the grab is strong but there also are no close buttons.

I tested this with Fedora 26 and the Gnome 3 desktop. and could not reproduce this. So maybe it got fixed upstream.

pinentry-curses on the same terminal as the application was never intended to be automagical - from the start it was clear that during any operation that may trigger a pinentry dialog, the application would have to stop reading from the terminal, and it would have to redraw the screen when gnupg finishes. That's just a limitation of the terminal that can not be overcome (there is no focus grab, no save/restore of the terminal state, etc). This needs to be raised with the emacs developers.

regarding the

Except for some tangential lingering questions, all issues in this report are attended to, and all subtasks are resolved.

result 1 (working):

Given that 2.0 reaches EOL in 6 months and the bug has been here for ages, I won't backport it to 2.0 anymore.

I don't yet understand your problem. What has this idle configuration to do with the way how we calibrate the loop. After all we are not idle while calibrating but are heavily employing the CPU. Can you please elaborate and consider that times(2) is a POSIX API and clock ticks are an essential POSIX feature.

Done in e57bcb7a2acff3a61a342d24e6a55407bf736631

Thanks. Indeed we should have better error codes. However, passing all error codes from the backend to the user is not useful.

This was resolved upstream by using no-grab (and otherwise would rather seem to be a bug in Gnome 3 classic mode anyway).

That issue is best taken up with the enigmail maintainers. If you report it there, feel free to add a link here. Thanks!

I can't reproduce this in Fedora 26. If this is still an issue, please reopen and provide more information. I tested pinentry-gnome3, pinentry-gtk-2 and pinentry-qt.

I am using Debian 9 with the packaged versions. For gnupg this is 2.1.18.

@aheinlein we need to know the gnupg version you are using with GPGME.

There are no team encryption keys, that's the problem. So there is at least a dependency between the tasks, as we can't document what we don't have.

I don't see how this duplicates T3074. If the web form is going to encourage people to ask for the team's encryption keys, it should just provide the encryption keys directly.

Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.

Fixed in 6053cb4f. The third patch was obsolete due to use of FIND_QT macro.

I've since tried neomutt-20170707 which includes stbuehler's patch, but I see the same error cases as before.

Note that the documentation clearly says that --nameserver expects an ip address. Now we could make it accept a port too, but that would not make the OP happy, as he wants to talk to localhost, but in tor mode, all dns requests are routed through tor (this is actually one of the main motivations for using a custom DNS resolver).

In T3240#99654, @im0nde wrote:

Neverthenless, I would be interested in other solutions that allow me to keep gnome-keyring installed alongside, as I would like to use it for other applications.

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

Fixed in 1e68f93dc547ae75b921e43db35e3599de92e2cb.

Thanks, LD_LIBRARY_PATH solved the problem

This is a bug tracker, not a support forum.

That is a matter of taste. A line requires a LF - many tools even ignore the last line or print a warning for a missing final LF. Not having a final LF is a bad idea.

We have to check what happens here, because list-sigs should be fast.

Yes, please please raise the priority on this. I just spent 15-30 minutes looking through tons of emails on lists saying to use --with-fingerprints and wondering what the heck was wrong with the people posting that until I saw this bug. Please raise priority, please fix.

I fixed the typo. The actual process is the same as described in https://www.gnupg.org/documentation/bts.html, see also T3074.

The sqlite backend was a little experiement that I did and it will not be merged.

I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:

applied the following patch and the package built successfully. thank you!

Oh well, the usual IBM enum/int problems. It bugs me since the OS/2 days. I am not sure why you experienced it only now. One of the wrong return types is there for ages. I pushed fixes for master and 1.7.

Hi, I found a workaround for neomutt (see https://github.com/neomutt/neomutt/pull/662).

In T1938#99890, @marcus wrote:

It's unclear from the discussion if this issue has been resolved.

With an integer overflow.

This is a standard dynamic sized array:

Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).