Should be resolved. Reopen if it is still an issue.

@aheinecke did you change the default?

werner says it's not a bug.

gpgtools will have to update.

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.