This is fixed.

This should be fixed.

About importing, there are two other works: repairing and trustdb update. We can figure out the difference by the --import-options of no-repair-keys and fast-import (to skip those works).
I think that both can be O(N^2) for number of signatures.

A linked list of 100000 items is not a usable data structure. The problem however is not the linked list but the DoS due to the number of signatures being well beyond the design limit. 1000 key signatures is already a large number and only few people have them. We need to put a limit on them.

with @gniibe's patches applied, i profiled the --import, since that is where the largest CPU cost remains. I tried two different times:

I disabled the dependency rules for the figures (it's only enabled for maintainers).

@gniibe: We move this issue over to mail. I'll forward it to you.

Okay, for 100000 signature this is clearly a win if no key lookup is needed.

Fixed.

i also checked the CPU time for git tag -v, whether @gniibe's patches were applied or not.

fwiw, i tried gpg --import on the ascii-armored version of my C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 OpenPGP certificate (22895014 octets, 54614 certifications), followed by gpg --list-keys and gpg --export | wc. I was comparing 2.2.17-1 (from the debian package in unstable) with the exact same source, just with @gniibe's two patches rG33c17a8008c3 and rGa7a043e82555 applied as well. I did this with GNUPGHOME set to an otherwise empty directory, where i had done touch pubring.gpg to avoid the keybox format. (the two runs did not share a GNUPGHOME).

If I were testing more, I would generate many (say, 1000, or more, for example) encrypted message by the tool (IBM Encryption Facility), to examine by GnuPG and figure out some patterns of failure.

While I only observed the output of --list-packet, what I see are:

With NTBTLS, it seems it works correctly.

Which SSH client are you using?

For the particular problem of --list-key with pubring.gpg, I think we can say it's fixed.

@werner : Yes, the way to go is having something like a server for keys; It can remove all unnecessary search/lookup all together.

Check out the mailing list gcrypt-devel@

Folks, I was just wondering if I could get an update on where we are with this bug. It seems we aren't sure if it's a real issue or not. What's the latest thought?

(i think that rG33c17a8008c3ba3bb740069f9f97c7467f156b54 is also relevant, though it was not tagged with this ticket)

@gniibe -- thank you very much for tracking down these O(N^2) operations and cleaning them up. I will profile the effect of those changes and report my findings.

Hi Maximilian,

Hi, @JW-D, as the 'fixed' version of mailvelope has been released, could you please confirm if the issue is solved for you with mailvelope 3.3.1, or if you're still affected? Thank you.

@gniibe: I doubt that your fix really makes a difference. The majority of time is spend on searching the keyring for keys. This is why I have the gpgk thing in the works.

You probably have one of the spammed keys in your keyring. This is a problem with the keyserver networks. Do not use --auto-key-retrieve and avoid using the keyservers until we provide a mitigation with the next gpg4win/gnupg release. See also T4591

yes, python2.7 and python3.7

Using several python versions?

rM7d0a979c07d2 disabled the test for this. @werner says:

Because this is a GPGME bug.

why is this fix not relevant for the 2.2 stable branch? I've had no feedback on this proposed patch.

Quiet tricky to get right; needs some rework.

I closed this as a duplicate of a newer task because I did not find this issue when creating T4561 and there was already work done for T4561.

Not every incoming certificate that has no user ID will lack a user ID once it is merged with the local copy of the same certificate. T4393 describes that use case, so if you're interested in receiving user-ID-lacking updates to certificates that you already have a copy of, @jaymzh, you should follow up on that ticket.

Once a revocation is added (to any part of the certificate), perhaps all the certification packets that are clearly made obsolete by the revocation could be dropped from the certificate? That would certainly free up space to be able to import additional revocations if needed.

Given the recent problems with the keyservers, I expect that the keyserver feature will go away anyway and thus I do not think we will put any more effort into this. Thus I re-tag this as gpg 2.3.

And of course, thanks for your fix.

Applied to both branches. I have run no tests myself, though.

Fix will be in 2.2.17

Fix will be in 2.2.17.
See T4612 for the revocation case.

Re 1.: I don't view this as a bug. gpg prints stats on what it has been done and clearly it has processed a key. If it would have imported the key you would see another stat line telling about this. There was however a bug in the stats output which has been fixed.

Because we use dot-locking in GnuPG and copy-update-write for keyrings. Granted: For gpgv this is not required but the code is identical to the gpg code and adding new code does not make much sense. After all gpgv is a stripped down version of gpg I once wrote for Debian. I see your use case but tehre are other ways to do this and thus anthing here has low priority.

Aha, thank you. Sorry I saw the original post about the flood attacks (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) which said to change your keyserver and I did, but I hadn't realized there were such significant differences.

I think what you're missing is the keys.openpgp.org documentation which makes it clear that they will not distribute identity information (read: "User IDs") without an explicit confirmation by the operator of the e-mail address named in the User ID. They strip down the certificate pretty significantly before redistribution, especially if the e-mail address hasn't been confirmed directly with the operators of that server.

I know the keyservers have been under attack, I'm using 'keys.openpgp.org' which is supposed to be more resilient to these, as I understand it?

out of curiosity, why does gpgv need the name of the file?

In that case, you can treat this ticket as a bug in the documentation, which still needs to be resolved.

We need random access and the name of the file. Thus a file descriptor is not sufficient.

Okay, if an attacker exactly hist that limit your case is valid. I see no easy fix here, though. What we can do is what is done on Unix file systems to give average users a disk full erroreven if there a few percent of the disk is free; root can use that extra space then. Revocation certificates would be what root is on Unix file systems.

That was pretty easy to reproduce thanks to your still not working server.

I did some manual tests using netcat and KS_FETCH to test the redirection.

I think you're suggesting accepting *any* path if the hostname of the proposed redirection matches openpgpkey.example.org when querying the WKD direct URL for an @example.org address. That would also be a fine solution from my point of view.

I head the same idea when I read your configuration. Given that the advanced lookup was not reallydeployed (see T4590) I also expect that we will receive complains now that it works. Thus white listing any "openpgpkey." seems to me a reasonable easy solution.

Will be in 2.2.17

Oh dear, that happens if one is always on master. I simply forgot to cherry pick the change from master back in November.
Two commits, though.

my initial scenario is where an adversarial keystore floods a certificate right up to (but within) the 5MiB boundary, so that the user has stored it in the keyring already. Then, the user encounters the certificate again, with revocation attached.

@werner, thanks for the pointer to the report, that's certainly useful. And i'm happy that organizations like SektionEins are doing GnuPG audits and publishing their results regardless of who paid for them.

@jaymzh, I agree with @werner that without more information, this bug report isn't particularly actionable.

I don't think so. The fallback mechnanism will still work and remove everything but valid self-signatures. This gives enough space to write the keyblock with the new revocation certificates. I am not sure about designated revokers in this case.

See https://sektioneins.de/en/blog/18-11-23-gnupg-wkd.html for details. In short they fear that companies using IP based security for internal services can be attacked via redirect request and in particular becuase that can happen in the background without the user noticing. I am not concerned but we had long lasting discussions also with protonmail about this and the result was that we need to have this protection. We do not know who requested and paid for the audit from SektionEins and they won't tell us.

I do not understand your problem: The keyserver does not carry or is willing to send you the requested key. Note that keyservers are for a year now under heady DoS attack and only a few are remaining. I will close this report, please re-open if you figure that it might be a bug in GnuPG.

as a separate variant: if the attacker floods the certificate with bogus self-signatures -- that is, certifications that have an issuer fingerprint or issuer key id subpacket, whether hashed or unhashed -- will that make it impossible to import any of them?

Thanks for working on this fallback, Werner.

Thanks, this is excellent news! I´ll check it, if the new Mailvelope version is available and I´ll let you know about the outcome. If the new version is released, let me know!

Thanks for the pointer, @werner. Certainly we want T4590 fixed.

This seems to be the same issue as the one opened in mailvelope. https://github.com/mailvelope/mailvelope/issues/679.

We need to rewrite the Location to avoid a CSRF attack. See fa1b1eaa4241ff3f0634c8bdf8591cbc7c464144

I cannot do that because all listed above packages are my own products.
Fedora is not execution test suites in more than 90% of all packages so they are not aware of most of the issues exposed by test suites.
Please focus on possible causes of above tests.
I'm opened on any suggestions to make additional diagnostics.

Thanks. You may want to ask on the mailing list gnupg-users to see whether someone else has had problems building on rawhide. Right now we do not have the time for individual support and thus I unfortunately need to prioritize this bug report down.

[tkloczko@barrel SPECS]$ uname -a
Linux barrel 5.1.5-300.fc30.x86_64 #1 SMP Sat May 25 18:00:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[tkloczko@barrel SPECS]$ rpm -q libassuan-devel libcurl-devel libgcrypt-devel libgpg-error-devel libksba-devel libusb-devel npth-devel openldap-devel pcsc-lite-libs gnutls-devel sqlite-devel
libassuan-devel-2.5.3-2.1.fc31.x86_64
libcurl-devel-7.65.1-2.fc31.x86_64
libgcrypt-devel-1.8.4-4.1.fc31.x86_64
libgpg-error-devel-1.36-2.fc31.x86_64
libksba-devel-1.3.5-10.1.fc31.x86_64
libusb-devel-0.1.5-14.fc30.x86_64
npth-devel-1.6-3.fc31.x86_64
openldap-devel-2.4.47-2.2.fc31.x86_64
pcsc-lite-libs-1.8.25-2.1.fc31.x86_64
gnutls-devel-3.6.8-2.fc31.x86_64
sqlite-devel-3.28.0-2.fc31.x86_64

Still about half of the packages are from Fedora rawhide but rest are mine.
Just checked and the test suite fails exactly the same way even started without palatalisation.

Also pushed to 2.2. Right now I can't see what else can be done, so I change the status to testing.

Please share with us the OS used, the versions of the libtaries used and other configuration information.
Also please run again using "make check" without any extra options.

Kleopatra was already using this keyserver at the time i took the screenshots, which is why i opened the ticket since it was working in the command line.