Pretty obvious. Thanks.

Hmmm

You seem to accept it. So Normal Prio and assigned to you :-p

Just as a note: I think the main selling point of GnuPG is that its stable. We care about backwards compatibility and we (are || want to be) rock solid. Even if there is a rare race. With millions of installations, that race will happen regularly. So I really would like us to get all this fixed without losing to much performance by locking to much.

Happens though. With the test invocation above there is only one key in the keyring.

1.9.0-beta68

Well, it should not happen if you always use the same key.

There is indeed a race condition between the passphrase cache and the pinentry invocation. There is even a comment on this somewhere in the code. The problem is that we would need to lock almost everything to avoid this rare condition.

Which Libgcrypt version?

Forgot to mention. run-threaded is a new test tool in GPGME.

I can reproduce it if I enter your or an unknown IP address.

I think this is resolved by kleopatra's watchdog. There is a bug that the agent becomes unresponsive somehow then the loading also hangs but this is unrelated to kleopatra.

Sorry I did not see your first comment.

I would change gpgme_addrspec_from_uid and the gnupg equivalent to strip out the subaddress.

It does not make sense to handle this in the protocol. The client should always ask for joe@example.org and thus keep the whole thing mostly out of gpg. This requires that keys are not created with sub-addresses. However, if someone has a need for this, this strategy should work:

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

Fixed in master and 2.2.

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

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.