I implemented that in master. The first output is from an update of your key and the second from an insert of a new key.

That won't be easy to debug unless we have intermediate debug values from the generating implementation. That IBM Encryption Facility looks partly similar in the command line options to gpg so I wonder whether it will be possible to get some debug output. @mrdave19: we can continue by private mail in case that is helpful for you (wk at g10code com)

I should add that i don't really care whose fault it is if the software is broken by some downstream. if it harms any users, and we can fix it, we should fix it, especially if the fix is easy.

We're writing free software, which we know that people use and modify downstream. if we know that the software has a particular sharp edge that people who are modifying it are likely to cut themselves on, we have two options:

Come on, if someone changes the software and breaks it, it is their's fault ant not ours. The whole thing on which keyserver and certificate to use as been discussed ad nausea in the past. Given all the problems with the keyservers I do not see a reason to change it right away to a state we had before. Keyserver code is pretty hard to test and has thus always been prone to regressions.

(See T4175 why this changed in 2.2.12.)

Even if you can't use it the option is still useful to avoid other kinds of DoS. As written in the comments it is not a full solution but it helps to side-step issues with key-signature. In particular for sites which do not have a need for them.
BTW, revocation certificates are still merged with the new option.

Hello,

I have no idea – I’m not familiar with cmd.exe – Do you have step by step instructions on how to do this?

Many thanks,

Chris Baillon
Digital Marketing Manager

Mainline Tel: +44 (0)1895 813 000
Fax: +44 (0)1895 200 541
E: chris.baillon@allpondsolutions.co.uk<mailto:chris.baillon@allpondsolutions.co.uk>
[cid:image013.jpg@01D48584.F61733C0]
[cid:image014.jpg@01D48584.F61733C0]https://www.facebook.com/allpond/[cid:image015.jpg@01D48584.F61733C0]https://www.instagram.com/allpondsolutions/

[cid:image016.jpg@01D48584.F61733C0]
[cid:image017.jpg@01D48584.F61733C0]https://www.facebook.com/allpetsolutions/[cid:image018.jpg@01D48584.F61733C0]https://www.instagram.com/allpetsolutions/

W: www.allpondsolutions.co.ukhttp://www.allpondsolutions.co.uk/

W: www.allpetsolutions.co.ukhttp://www.allpetsolutions.co.uk/

All Pet Solutions Ltd is a company registered in England and Wales.
Unit 203| Riverside Way | Uxbridge| UB8 2YF

Please consider the environment before printing this e-mail.

This email, including attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received this email in error please notify the sender and delete it from your system. Emails are not secure and may contain viruses. No liability can be accepted for viruses that might be transferred by this email or any attachment.

All Pet Solutions Ltd. Registered office: 22 Wycombe End, Beaconsfield, Buckinghamshire, England, HP9 1NB. Registered in England and Wales. Registered No. 05678076

From: aheinecke (Andre Heinecke) <noreply@dev.gnupg.org>
Sent: 01 July 2019 07:44
To: Chris Baillon <Chris.Baillon@allpondsolutions.co.uk>
Subject: [Task] [Claimed] T4581: Kleopatra stuck in loading the certificate cache

aheinecke triaged this task as "Normal" priority.
aheinecke claimed this task.
aheinecke added a comment.

Hi,

can you please open the console (cmd.exe) and do a "gpg -K" and "gpgsm -K"

do these commands list all your secret keys or do they hang?

Also please try killing the process "gpg-agent.exe" through the Task manager and try to open Kleopatra again.

Regards,
Andre

TASK DETAIL
https://dev.gnupg.org/T4581

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, allpond, Neurone, Rafixmod, Fox, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

If the default keyserver is not hkps.pool.sks-keyservers.net, then @kristianf's CA certificate has no business certifying it.

Welcome back from vacation!
@aheinecke Yes I am 1000% sure the passphrase is "dave" without the quotes.
These are the commands I use for the encrypt using the IBM Encryption Facility:

-o '/home/suimgwy/_july1.pbe' \
-s2k-cipher-name AES_256 -s2k-digest-name SHA256 -s2k-mode 3 \
-s2k-passphrase dave \
-t ISO-8859-1 \
-use-mdc \
-c '/home/suimgwy/_input.txt'
<<<

thanks for working on this @werner. rG2e349bb61737 is definitely not useful for me. If i am going to tell anyone "hey, do this weird thing differently in order to fetch my key", i will tell them "pull it from https://dkg.fifthhorseman.net/dkg-openpgp.key". I will never tell anyone to use import-self-sigs-only.

Ping?

That is probably not what you want but at least it allows to import your key

back from vacation so apologies for the delay. @werner This is reproducible on the command line without Kleopatra. So maybe something for you our Gniibe to look into?

I have mentioned it several times in the past that I would like to see the search by user id feature be removed from keyservers so that there is less incentive to use them as a perpetual and searchable database for maybe illegitimate data.

I see no need for this.

Keyserver issues are always hard to analyze because the state of the servers and which server you get is always a factor.

Sorry for the delay, I was on my summer vacation ;-)

can you please open the console (cmd.exe) and do a "gpg -K" and "gpgsm -K"

@joaociocca Can you please try to update to Gpg4win-3.1.9 and try again.

I've just pushed 1c9cc97e9d47d73763810dcb4a36b6cdf31a2254 to the branch dkg-fix-T4593

Note also that some keyservers like keys.openpgp.org will distribute only verified self-sigs (including revocations and subkey updates) without distributing the floodable third-party certifications. We can and should distinguish "updates-only" keyservers from discovery-by-address mecahnisms.

Just importing a ~666KiB certificate when this monster certificate is in the keyring consumes over 10m of CPU time:

Verifying a git tag from the "clean" version of this certificate takes ~225ms of CPU time. Verifying the same git tag from a keyring that contains the flooded version of the certificate takes ~145s. This is factor of more than 600×. Any automated git tag verification system can probably be DoSed by this behavior.

I didn't mean to suggest that switching to sqlite was the only way to fix this, but if it is a promising way to fix it, that would be great. I'm sure there are other ways.

I recognize that adding network activity to the test suite can be complicated (not all test suites are run with functional network access), but if it is possible to have a unit test or something (that doesn't do network access, but just looks at what the dirmngr *would* have tried somehow?), that would be great. Thanks for looking into this!

i'm aware of the filters you're using, but they are not a principled response to this kind of certificate flooding attack. An attacker who wants to be really abusive can easily create certifications that bypass any import-filter gpg is capable of.

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.