PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL:

Patches send to mailing list:
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004800.html
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004799.html

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.

Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html

It has now been more than a month since:

And also this is excellent point.

reviewing this, i think the situation is:

Sounds interesting @stm! Are there technical documents or specifications I could read to dig into details?

@dkg First step toward the canonical OpenPGP certificate export: http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=75372cac01501ae427dec1ae18805449bf28d087

@wiktor-k Thanks for your interest.

Except w32_system function, it's done.

Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.

Hi everyone,

In general, if it requires more time, a reader can reply with time extension.

@werner wrote:

Other tasks in master are right now more important.

Other tasks in master are right now more important. You need to wait a bit more.

So, what about this? If I recall correctly, we had agreed in the call to merge this patch, at least into master?

Thank you. Merged.

@werner I would be willing to share 20% to the reviewer of my patches. (or 25% in this case, as @jwilk went through the effort to even write a test to point out a bug in my code). However, so far that has been entirely @jwilk who has been reviewing my patches.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.

Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.

I don't know why dkg-fix-T4641 is not showing up here on the assuan git repo.

@dkg You are right. The term "issuer" was too ambiguous.
I like your proposal and would try to implement it. However, "export" of dkg-keycheck and other programs from DKGPG are very limited.

I've just pushed rA45f01593d4ce794ae3562359aee2ff80c97e368e to the dkg-fix-T4641 branch that resolves this.

Thanks for the feedback. I'll go ahead and close any tickets that come in via debian that expect to be able to cross compile without having at least once had a native compiler on the platform to generate the appropriate lock-obj-pub-*.h.

In fact this specific scheme of indirect access to pthread objects is there to minimize dependencies of libgpg-error. It makes cross-compiling a bit harder but that is anyway the case because you need to check a lot of things for a new platform.

It is on on my private todo list but thanks for opening a public issue for tracking.

@stm it kind of is a last-resort already, given that it's only in the event where the signature creation dates are equal, but sure, i wouldn't mind adjusting the proposal to say that (sigs) means "sort by date, then issuer, then binary content" -- but what do we think "sort by issuer" means?

Please do not change the priority back. That is a maintainer's task. I consider this along with adding replicas of issues to a bit rude.

Please do not change the priority back without discussing this with the maintainer first. Thanks.

Due to T4628, i no longer think that import-clean is a good idea by default.

Maybe GnuPG could display a prompt if it detects a pubring.gpg and no pubring.kbx. Something like:

It turned out to be a downstream issue and the change in message class was enough from our side.

We as GPGTools would also like to see this addition being integrated into GnuPG, since we do plan to switch to keys.openpgp.org in the near future, as we have long been hoping for a key server with better performance and among other things email verification. Without this change, revocations would not work as expected in combination with hagrid however. Preferably of course in the 2.2.X branch.

I pushed my change as: rT7b2c4d9dd50b: Support GCM.
Please test.

then they are sorted by their binary content.

No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.

That is a limit for the web key service to publish a certificate. IIRC, Debian developers do not use this but Debian creates the WKD from a database.

This is especially relevant if you are not going to implement the fallback to import-clean that was proposed in T4591.

I see that you have lowered the WKD limit to 64KiB with 6396f8d115f21ae15571b683e9ac9d1d7e3f44f4 -- i think this is a mistake, as reasonable certificates can be several times that size (e.g. zack's cleaned certificate, mentioned above). I'd prefer a limit of 256KiB.

and from my understanding they are sending the self-signatures anyway.

This is not just about keys.openpgp.org. It's about any keystore that implements user id redaction, for whatever reason. When you say "what they can do is accept only user ids which…" i think you mean "the userid-redacting keystores can instead redistribute user ids which …". Is that right?

I think we should not backport this to 2.2 - okay?

Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. posteo.de for example requires this for years and the WKD drafts has a feature to support this.

You are right. I again mixed this up with gpg-wks-client. Over there we have a limit implemented unsing --max-output to avoid compression based attacks.

@werner, i don't think there is a 64K limit either, at least not in 2.2.16. Here is 2.2.16 with an empty homedir fetching Zack's certificate here which is > 97KiB:

Just want to weigh in here to say this would be incredibly useful given the shift to the new keyserver model. See T4604 for more context.

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.

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!

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

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.

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.

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

I somehow expected such a feature request ;-). However, I do not think that an automatic migration is is appropriate for the stable branch.

In T4597#127637, @Valodim wrote:

Done. Hopefully this works now :)

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

Done. Hopefully this works now :)

Anything using CBC mode - ECC is just fine.

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

They can't agree on a common ciphersuite. The reason is that the server does not support any CBC mode. Which is a bad idea because CBC is still a very common cipher mode.

Okay, so the open task is to build gpgme with MSVC in a way that different libnames are used and that we can distribute them along our standard DLLs? Given the easy we can now ssh into Windows there won't be a need to Wine things.

One issue with this is that Qt Webengine (chrome) cannot be built with mingw. Fixing that would be a major project.

High priority and half a year no action....

sorry to keep pinging this, but given the ongoing flooding attacks (e.g. T4591) and how SKS and similar keyservers are unable to safely transmit flooded certificates, i think this kind of fix is urgent if we expect gpg to be able to retrieve revocations safely. What's the status here?