gpg 1.4 will now only receive important updates, and this is a change in behavior, which might break scripts.

I don't know if decryption method was changed, but at least the "can't sign using" message appears to be unchanged yet (from looking at the source code).

werner said he doesn't like the proposed solution, so this is a wontfix.

Note that current versions don't install a skeleton conf file anymore.

I just verified that this is indeed fixed.

@marcus sure, but I am currently away on vacation and won't be back until mid August. Also, I'd need some detailed build instructions (I'm on mac os) since I'm not very familiar with building C code - I brew installed gpg.

Hi Justin

In T2923#100519, @dkg wrote:

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

this discrepancy is easily explained. You are entering a date that is interpreted as UTC, and it is echoing it back using your local time zone. PST is UTC−8:00, matching the output.

Can you provide samples that highlight the problem?

I'm re-opening this ticket because i think Valodim has clarified what he meant, which is different than what werner closed the ticket for.

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

Note that T2923 includes a patch that might help.

My point is that without clear documentation of what is expected, it's pretty hard to tell whether the code is even working or not. Sounds like it isn't :(

Is this correct?

I don't think this issue is actually resolved. there's a feature here (i think) but it's not documented to the point where anyone can figure out how to use it. If there's no way to use it, the feature should be removed (or at least deprecated).

Ah, ok, thanks for the info!

Likely fixed by commit a4d1595a2638db63ac4c73e722c8ba95fdd85ff7 (rijndael-aesni: split assembly block to ease register pressure) in 1.7 branch (and included in 1.7.3+).

I tried to find evidence that such a change ever landed in 2.0. I now believe the mistake is in the NEWS file. As 2.0 is nearing EOL, we won't backport this.

Well, yes, it's not general authentication like AE provides, didn't think this through entirely. However, handing encrypted data to gnupg and then not being sure if it was actually decrypted with a passphrase makes even the confidentiality property questionable.

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.