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.

I tried to implement this but this is troublesome for other programs using the interface because a common patter is to use --search-keys to get a listing and then use --recv-key to import the keys - That won't work and will require changes to --recv-key too. Thus this change will not go into 2.2. Anyway, it is not dangerous to have --search-keys because the new default for import from keyservers will be to strip all key-signatures.

Well, I mixed this up. On sending a a new key to the server export-minimal is used. Receiving a key uses keep-uid=REQUESTED and a 64k limit.

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?

I'm also interested in fine details especially w.r.t. interfacing with GnuPG. I've seen multiple timestamping standards starting from RFC3161, to blockchains or secure time protocols even (ab)using Certificate Transparency logs and ideas on how to append the signature (timestamp flag vs unhashed notations) so I'll be eager to hear the details on the ML @stm!

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

in 2.2.16, anyway, gnupg does not appear to apply import-minimal for WKD.

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.

Indeed we are in urgent need for a timestamping service. I was already pondering with the idea to integrate existing X.509 stamping services into OpenPGP signatures. Please write to gnupg-devel if you want to reach a wider audience. Unfortunately I need to abstain for getting involved in your project; there are too many other things to do.

One reason is that you may want to look at older key- or self-signatures which import-clean removes. I can imgine use cases where this has been used for something. People are ofteh doing inetresting things with standard tools.

Recently, I started a new project at savannah for developing free software and documentation in order to operate a Distributed OpenPGP Timestamping Service. Everyone is welcome to join.

@dkg I believe @aheinecke gave the GpgOL description just as an example of why WKD-first retrieval would be beneficial (for details of that see https://wiki.gnupg.org/AutomatedEncryption#Trust_Levels) and I believe this ticket is a follow-up to my question on gnupg-devel ML: https://lists.gnupg.org/pipermail/gnupg-devel/2019-June/034372.html

auto-key-retrieve happens in the context of signature verification when the certificate is missing. If no signer User ID subpacket is present in the signature, then WKD simply won't work.

hm, i see your point. If you could spell out what the specific regression(s) in more detail, though, that might help us to reason about their impact.

I agree for keyserver imports. For all other imports this would be a severe regression and thus the wrong thing to do.

I asked you to carry this to a mailing list and not re-open this task.

if you want to add a separate subcommand for that, i would be happy to abandon migrate-pubring-from-classic-gpg.

My plan is to let --search-key be the same as locate-key but without local lookups, thus it will be the same as

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 somehow expected such a feature request ;-). However, I do not think that an automatic migration is is appropriate for the stable branch.

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.

In T4597#127637, @Valodim wrote:

Done. Hopefully this works now :)

https://www.ssllabs.com/ssltest/analyze.html?d=keys.openpgp.org

@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.