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.

as a separate variant: if the attacker floods the certificate with bogus self-signatures -- that is, certifications that have an issuer fingerprint or issuer key id subpacket, whether hashed or unhashed -- will that make it impossible to import any of them?

Thanks for working on this fallback, Werner.

Thanks, this is excellent news! I´ll check it, if the new Mailvelope version is available and I´ll let you know about the outcome. If the new version is released, let me know!

Done. Hopefully this works now :)

Thanks for the pointer, @werner. Certainly we want T4590 fixed.

This seems to be the same issue as the one opened in mailvelope. https://github.com/mailvelope/mailvelope/issues/679.

Anything using CBC mode - ECC is just fine.

We need to rewrite the Location to avoid a CSRF attack. See fa1b1eaa4241ff3f0634c8bdf8591cbc7c464144

Which is a bad idea because CBC is still a very common cipher mode.

I cannot do that because all listed above packages are my own products.
Fedora is not execution test suites in more than 90% of all packages so they are not aware of most of the issues exposed by test suites.
Please focus on possible causes of above tests.
I'm opened on any suggestions to make additional diagnostics.

Thanks. You may want to ask on the mailing list gnupg-users to see whether someone else has had problems building on rawhide. Right now we do not have the time for individual support and thus I unfortunately need to prioritize this bug report down.

This issues is not really about the CRL's. GpgOL should not activate the EFail protection if a CRL check fails. That is the issue here.

[tkloczko@barrel SPECS]$ uname -a
Linux barrel 5.1.5-300.fc30.x86_64 #1 SMP Sat May 25 18:00:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[tkloczko@barrel SPECS]$ rpm -q libassuan-devel libcurl-devel libgcrypt-devel libgpg-error-devel libksba-devel libusb-devel npth-devel openldap-devel pcsc-lite-libs gnutls-devel sqlite-devel
libassuan-devel-2.5.3-2.1.fc31.x86_64
libcurl-devel-7.65.1-2.fc31.x86_64
libgcrypt-devel-1.8.4-4.1.fc31.x86_64
libgpg-error-devel-1.36-2.fc31.x86_64
libksba-devel-1.3.5-10.1.fc31.x86_64
libusb-devel-0.1.5-14.fc30.x86_64
npth-devel-1.6-3.fc31.x86_64
openldap-devel-2.4.47-2.2.fc31.x86_64
pcsc-lite-libs-1.8.25-2.1.fc31.x86_64
gnutls-devel-3.6.8-2.fc31.x86_64
sqlite-devel-3.28.0-2.fc31.x86_64

Still about half of the packages are from Fedora rawhide but rest are mine.
Just checked and the test suite fails exactly the same way even started without palatalisation.

We need to know the issuers of the CRLs under question.

See also T4538 which we can only fix in 2.2 after we have checked that this does not break the VS-NfD approval.

Also pushed to 2.2. Right now I can't see what else can be done, so I change the status to testing.

Please share with us the OS used, the versions of the libtaries used and other configuration information.
Also please run again using "make check" without any extra options.

Kleopatra was already using this keyserver at the time i took the screenshots, which is why i opened the ticket since it was working in the command line.

I implemented that in master. The first output is from an update of your key and the second from an insert of a new key.

As I said we do this with all GnuPG components. Pinentry is a bit of exception because it is an external package.
I have also had bug reports which later turned out that a wrong pinentry was used; I prefer to know eactly which pinentry is used. Regarding your concrete problem I suggested to add a note with the full name of the pinentry or to change the error message to something better understandable.

That won't be easy to debug unless we have intermediate debug values from the generating implementation. That IBM Encryption Facility looks partly similar in the command line options to gpg so I wonder whether it will be possible to get some debug output. @mrdave19: we can continue by private mail in case that is helpful for you (wk at g10code com)