I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?

Fixed in master and 1.8.
@dkg: Thanks for the comments and your patience to convince me.

The next step is to release libgcrypt 1.8.4 :-)

Fixed in master and 2.2

Oh, that is really old code dating back to dirmngr-1. There is only one user I will see whether I can replace it with the generic parser we have in http.c

Now that is funny c+p code. I vaporized it to just a few lines.

It seems that this part of the code was not finished. Unfortunately upstream of the dns code is unresponsive and thus we started to maintain the code base by ourselves. There is still an open question whether we should do that to the full extend, in which case we would integrate the code closer into the GnuPG framework with its own logging subsystems.

Thanks.

Thanks.

Thanks.

Thanks.

Thanks

Thanks.

Thanks. May also happen if the first print_assuan_status fails.

Dear aheinecke,

Hi Adam,

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.