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?

For the record in my original message I asked about adding self-signatures.

It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?

A possible exception here is that .onion TLDs should stick with HKP by default

I note that "the best" seems like it might be a pretty subjective thing. The standard GnuPG framing asks about the validity of keys for the User ID in question. Perhaps the caller could indicate whether they want to require full validity for each key to make this key selection more strict.

The function would do something like:

• from msg, extract all e-mail addresses from to, cc, bcc fields
• find "the best" keys that match these addresses, storing them in keylist
• copy msg to tmp, remove bcc header from tmp
• wrap armored output of gpg.Context.encrypt(bytes(tmp), recipients=keylist) in the necessary RFC 3156 cladding, copying most headers from msg (maybe stubbing out the subject), producing an email.message.EmailMessage object.

we now have a DCO from @Valodim

@werner, My usual approach for private branches is to prefix with dkg/, but (a) playfair rejects branch names with a /, and (b) i'm not the author of these patches, and i didn't want to claim credit that doesn't belong to me.

Please use a private branch as usual. There has been no agreement or a discussion over this change nor do we have a DCO from him.

I've pushed @Valodim's proposed patches to the fix-4393 branch in our git repo. they look good to me, and i think they should be merged to master.

Nope

Here are the patches without any new commands:

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?

In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.

The change in message class did not help.

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.

gniibe wrote:

RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280. To be conservative, I don't include them now.

I pushed more changes to include modules in RFC 5911 and RFC 5912.

Comparing old cms.asn and new cms.asn, now I understand how RFC 3370 matters. I added those things back from RFC 5911 (which cites RFC 3370) which comes with BSD license for code.

@gniibe thank you!

I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
or:
https://dev.gnupg.org/source/libksba/history/gniibe%252Ffix-4487/
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=shortlog;h=refs/heads/gniibe/fix-4487