While I agree that it would be good for some useful comment to be generated, I'd currently settle for a way to manually set a comment on a key.

What are the next steps here? i confess i'm a little tired of doing regular checkins on this issue, and i'm sure other people are tired of me nagging. What can we do to move this along?

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

The fix was not fully correct because it considered a back signature's usage tool.

The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.

Ok. I was not aware that HKPS should already have the highest quality.

hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?

gpg: keydb_search failed: Provided object is too short

Interaction will be something like this:

Priority is high, because Gnuk Token requires this feature for testing its implementation.

Changes are included to master branch of gnupg.

Actually it fails only when you set TERM to the empty string. Unsetting TERM still works:

Thanks for your comments, Stephan.

@aheinecke -- @smueller_chronox.de (author of the comment above) is Stephan Müller from atsec. Glad to see he seems ok with the proposal :)

Apologies for not having read all comments in this long thread. I was asked to comment on the patch, so here is my comment:

Patch 0001 applied to master.

Thanks for your report. Applied.

Added gpgol and gpg4win project tags as this is important for these projects.

well, i tried to push, anyway, but it looks like playfair is rejecting my pushes:

@werner -- yes, i am asking for a change that is specific to the way that gcrypt interacts with the Linux kernel. The minor patch i've proposed only affects a codeblock within #if defined(__linux__), so i don't believe it would have an effect on other Unices. I hope that people working with other kernels will propose any necessary fixes for them.

Assuming dirmngr is just connecting to localhost on one of the following ports: 9050, 9150 or 8118 (maybe) then an interim workaround could be achieved with ncat (or netcat, or nc ... but ncat is like those two on steroids and will happily pass a shell exec function to connect to the remote host with openssl too (which may be preferred depending on the size of the LAN).

Release done with these major news:

• gpg: Refresh expired keys originating from the WKD. [T2917]
• gpg: Use a 256 KiB limit for a WKD imported key.
• gpg: New option --known-notation. [T4060]
• scd: Add support for the Trustica Cryptoucan reader.
• agent: Speed up starting during on-demand launching. [T3490]
• dirmngr: Validate SRV records in WKD queries.

@kallisti5: For you server you can add only_urandom to random.conf when changing to a multiuser runlevel and remove it early at startup and termination.

/dev/random, RDRAND, etc involves a lot of political arguments and thus it is not easy to decide what to do. What you are calling for is a linux kernel specific code path (note that rndlinux is used by most Unices) and won't be helpful for other OSes. I am of course willing to do add specific for for a few widespread OSes (and in any case for Debian). It is a major change and thus does not belong into 1.8 - I am fine with master which Debian might want to backport.

Well, Werner is just back so he can say more.
An excellent reviewer was Stephan Müller from atsec. He is also involved a bit afaik in the kernel random development.

@aheinecke thanks for the followup!

Well, I have already tried to explain the use case: To make using cryptography easier for our users (for most of them the command line is the hell ...) I have integrated GnuPG in our webmailer. The webmailer has a key management page where you can import and export keys (up- and download, import from mail, attach to mail etc.), where you can edit trust settings, and where you can sign other keys and revoke such signatures. The webmailer certainly does not offer all capabilities of GnuPG but certainly a substantial subset.

This seems very special and I'm not sure if we should not say at some point that we won't add quick commands for everything ;-)

I think that the ultimate decision here lies with Werner. Additional review.
I think the biggest obstacle is that we don't want to change the random gathering code if it can be avoided and that the random code has been thoroughly reviewed / tested and is currently considered secure.

This bug report has been around for several months now. it has a simple patch, a clear explanation, a report of running code, and examples of problems it solves.

I've now run the proposed patch on a GNU/Linux system where the kernel's RNG is initialized but /proc/sys/kernel/random/entropy_avail shows numbers below 100, and i can confirm that 3072-bit RSA key generation takes roughly 0.8 seconds: 20 sequential default --quick-keygen operations (each creating two secret keys) took ~32s.

Here is another example of users doing sketchy things to try to "fix" this process:

Here is an example of the kinds of UI/UX mystery that users face while this decision is unresolved:

The problem with mnemonics based on words is that they are language dependent and only a small part of the world is fluent enough in English to spell/use them correctly. Thus anything based on ICAO spelling (Alfa, Bravo,...) is a better choice than arbitrary words from one language. Even if that meas to write down a longer string. A CRC is of course very useful.

It would be great if this feature were implemented with a mnemonic code option, with a built in checksum, as described in bip39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Using the same bip39 standard (and perhaps others, as alluded to in T3497) would also improve compatibility with existing crypto key storage devices (i.e. cryptocurrency wallets used as smart cards).

Dear Andre , all , T4020 does not even well-define the symptom and I
do not agree T4020 is a duplicate of T4079 . I'd close T4020 in favor
of T4079 . Many thanks . Mirko

Hi Mirko,

@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?

Right, but requires extra code. The --quick commands try to reuse existing code and, iirc, that is the reason why a user id is accepted for --quick-add-uid.

We do have a history of extending the API, no?

I should have :) Thing is - a fix could be made in a backwards compatible way. So I don't really see your point.

The command line is an API and we will never break an API without a very good reason. If you didn't like that API you should have noted that on the devel mailing list years ago ;-)

And FWIW: an inconsistent UI/CLI should be treated as bug - not as a feature request.

You completely ignore the fact that --quick-add-uid and --quick-add-key are not consistent.
It's not clear why one should require a fingerprint and the other allows the kind of "user-id" you just described.
That was the main point of this issue.

The term “user-id” is used throughout gpg to mean some kind of user id beit is a name, a key id, a fingerprint, a keygrip, etc. See the section "How to specify a user id" in the man page. FPR is used if a fingerprint is required.

From the man page:

--quick-add-uid user-id new-user-id
--quick-add-key fpr [algo [usage [expire]]]

I am not sure wheat I understand your request. --quick-add-uid takes a fingerprint as first argument you _may _ use a a user-id instead but that is for consistency with all gpg commands. Using the fingerprint is always highly suggested.

About how the keys are actually stored on disk:

Release done: https://lists.gnupg.org/pipermail/gnupg-announce/2018q3/000427.html

Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.

Given that Cygwin is not supported I would understand if the bug is
closed or should I open a feature request to have Cygwin officialy
supported.
I would never the less appriciate any help/hint on how to be successfull
installing "gnupg" on Cygwin.

Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Ok yeah. I can aim for a Gpg4win for next week, too.

next week?

What is the ETA for 2.2.9?

It won't import that keyblock. We can fixup some trivial cases but there will always be ways to create a garbled keyblock and that is nothing we can fix. Better restore the keyblock from a backup or write a dedicated tool fsck-like tool.

What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?

Thank you for your prompt response and your suggestion for a workaround.

Got it. The reason was a broken translation. I've opened T4054 to fix in general that broken translations can cause crashes.

I can reproduce it with a german windows