Confirmed; that looks like a regression.

We know that. The problem is that we can't simply switch to sqlite for key storage because it is common that dozens of gpg processes are accessing the key data base. At least at some points we need proper transactional behaviour and Sqlite implements that by talking a temporary copy of the database - not an option for large keyrings.

I know this problem very well and it let to the introduction the import filters. For example I can update my own key only using filters like

Let me explain some technical detail for the record.

Because my fix was incomplete, I pushed another change to GnuPG master: rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM.
I also pushed my changes to pinentry master: rPf6e84ce0a34c: tty: Confirmation is not by line edit mode., rP531b92300c58: tty: Support line editing by system., rPb176a8ac0dcd: Exit the loop on an error with GPG_ERR_FULLY_CANCELED.

I note that this is likely happening because we are using gcr's system-modal prompter. I haven't looked into whether it's even possible to use gcr in a non-system-modal way, but i'd welcome pointers.

Although sometimes useful, reports about recent changes to the repo should not be filed as a bug report. You may comment on the commit itself, though.

I meant, GnuPG side was fixed in master, it sends SIGINT to pinentry process when gpg exits.

Ah, yes, that signal thing should be handled correctly, when we support line edit by tty.

Thank you. I just downloaded the source for pinentry-1.1.0 and changed this line:

(What you see as the link addressed in 2015 is for pinentry-curses, which is irrelevant.)

Whoops, looks like it, sorry for the noise.

i think this might be a duplicate of T4496

I'm unlikely to put a windows-specific patch into the debian source, as
i have no good way of testing it, and it wouldn't affect any binary that
we ship.

I just received answer that this is still a problem in the current release.

@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.

Hm, T4521 suggests that the two different cases should not be treated differently. If you think that they *should* cause distinct behavior, please do mention it over there!

There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).

Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.

I assigned the CVE, but yes it needs more facts.

Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.

The gpg --version shows:

Which Libgcrypt version is used (gpg --version shows it).

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

@gniibe, thanks for the diagnosis! I agree that restarting or shutting down the backends should be done in the reverse order as a simple workaround.

Correct solution is to implement KILLAGENT synchronously, but it's somehow harder to implement.
Easier workaround is modifying gpgconf like:

I found a race condition between KILLAGENT command and accepting another request.
Here is a patch to replicate the race condition :

I took this task as it has errors of gpg-connect-agent scd killscd. But, it seems for me that it's not the direct cause.
Anyway, I investigate the bug.

without feedback, i have no idea what you want to do here as upstream. I believe this issue has identified a specific failing use case, and it has a patch that fixes the problem. if there's a problem, please let me know what it is. If there's no problem, please consider merging.

Any word on this? i've pushed a fix for this into debian experimental as a part of 2.2.16-2, but i am concerned that there's no adoption from upstream. If there's a reason that this is the wrong fix, please do let me know!

Fixed in master, by using /usr/xpg4/bin/sh on Solaris.
Perhaps, some old Unix system like Tru64 would need same care.

I noticed it happens after entering the passphrase, and only using the
inline editor to answer.

If we only need it for backward compatibility, then the configuration in gpg.conf should *not* be overriding the preferred, forward-looking form of the configuration (in dirmngr.conf). If it is low priority to fix this, then there will be a generation of GnuPG users and toolchains which deliberately configure the value in gpg.conf instead of dirmngr.conf because they'll know that's the more robust way to do it.

@johng: I understand your problems and recall that Linux systems had a hard to time to replace all bashism with standard Posix. The problems with /bin/sh on Solaris seems to be even more persistent.

This seems to be closely related to T4257 for which I have a fix under test. The problem is that we pass the fd used by the caller to create the data object to gpgsm and close that very fd. The descriptor passing involves an implicit dup so closing is in theory okay but we should not close an fd which has been set (w/o dup) by the caller.

Fixed with gpg4win 3.1.9.

I wrote the script and the intention is supporting old systems using POSIX shell. Our goal here is: Not introducing (additional) dependency to Bash.

Thanks for your feedback Werner.

This is all valid Bourne shell syntax. In detail:

Thank you very much for your quick action!

Hi Andre,

Hi,
as usual, thanks for your help.

@gouttegd good catch!

The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.

Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.

I just assumed that is an ntbtls problem.

If I understand correctly, this is exactly the same problem that the one we encountered some time ago in the code dealing with fetching keys from HTTP (--fetch-keys), and that we fixed with this patch.

fwiw, the bug looks like it's in send_request in ks-engine-hkp.c, which re-uses the http_session object without re-initializing its tls_session member.

thanks for the triage, @werner!

We need --keyserver in gpg for just one reason: backward compatibility.

thanks for fixing that error message, @werner. As @Valodim points out in discusson about hagrid, a gpg.conf keyserver option (deprecated according to the documentation) overrides the dirmngr.conf keyserver option (not deprecated according to the documentation.

I'm having a very similar problem in 3.1.5! Randomly, when I try to view a PGP-signed e-mail, nothing shows, both on preview panel and when I open the message.