Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

Ah, ok, thanks for the info!

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.

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).

Laned in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

The revert was done in 7195b94345b0bb937477dc47fc5ec27fb108a099.

Landed in f7de6260936cafb5f56635956b55271baae72faf. Thanks!

Without more information, we can not act on this.

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

Landed in 1843485de9

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

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

What behavior do you expect in this case?

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

And SETQUALITYBAR.

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:

It is unclear what the benefit of such a console pinentry for windows would be.

Loopback is now officially supported, so I am closing this.

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.

I just tested this with Fedora 26, pinentry-gnome3 0.9.7 and Gnome Keyring 3.20.1. See below for a full trace. If this doesn't work for you, check that you have compiled pinentry with libsecret, and did not deactivate the feature in the gpg-agent.conf.

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.

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

Without a strong use case, I am closing this feature request. It may well turn out that like --allow-emacs-pinentry, the best solution in each case will be to add specific options, and then a generic pass-through will never be required. And we don't want to add features just in case somebody might need them in the future.

Landed in ebfa54e6044420ae12a090cdef9df7e7b0d961d2. Thanks!

Done in e57bcb7a2acff3a61a342d24e6a55407bf736631

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.

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.

Obsolete due to FIND_QT macro. Also see 6053cb4f

Fixed in 6053cb4f

Fixed in 6053cb4f

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

Done.

Landed in d24594976686

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

We don't support pkg-config, because it is not POSIX. See https://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028474.html for discussion.

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

Declare days_sq.

The problem I see is two-fold:

This is a standard dynamic sized array:

At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.

Maybe casting to a void* helps to disable the check in the compiler.

It's unclear from the discussion if this issue has been resolved. @werner can you please comment on this?