After waiting for far over an hour, Kleopatra read the keys. Now, things go faster (also in LibreOffice), but it still takes around 30 seconds, which is quite long.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 15 2019
gpg4win 3.1.10 did not fix this issue for me, neither in Kleopatra nor in LibreOffice.
The card frame works received a lot of changes in master but we won't backport it to 2.2. Sorry.
@gniibe, the documentation (at least on the stable branch) says that --fast-import is just a synonym for --import. is that incorrect?
Jul 14 2019
Maybe GnuPG could display a prompt if it detects a pubring.gpg and no pubring.kbx. Something like:
I also tested it with Outlook 2010 and there this did not happen. So it's probably save to assume that this was a behavioral change in some more recent Outlook Version.
This was released 2019-06-15
Has been released and confirmed to be working.
Fix is in, will be released with 3.1.10
Fix is in. Will be released with 3.1.10
This is resolved
It turned out to be a downstream issue and the change in message class was enough from our side.
This is fixed.
This was fixed with 3.1.9
This should be fixed.
Testing with the DGN certificate showed that GPGSM returns a signature verification error (invalid digest algorithm) in this case. So the signature summary is not even checked.
Jul 13 2019
Thanks for all the fixes! I can confirm commit dad35d65f05eb1c15589a7e4755dcae6aed2d6cf works just fine on all my machines (Linux & macOS).
Jul 12 2019
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.
Jul 11 2019
Is this really necessary to duplicate functionality that already is provided by Web Key Directory?
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?
gpg-agent side is fixed to relax the error handling.
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.
Jul 10 2019
I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.
Check out the mailing list gcrypt-devel@
Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.
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?
Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.
(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.
aiui, a keyserver scheme of https:// implies that the specific URL is to be queried directly, not using any of the HKPS URL path patterns.
We should put it of the agenda od the Brussesl summit in 3 weeks. I have a few ideas what we can do in gpg.