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

Perhaps i wasn't clear enough in the earlier messages on this thread. The inclusion of restrictively-licensed code in a file that also claims LGPL/GPL appears to be an unredistributable license. Could you please clarify why the GPL or LGPL applies to libksba while it contains src/cms.asn in its current form?

Fix pushed.

I think that detecting strerror_s by configure is better, because it's a new feature on Windows.

I doubt that we are going to implement this.

I guess we can do that. Thanks for the hint.

The behaviour related to ssh key access is due to the way ssh works: After a connection has been established to a server ssh presents to to the server all identities (public keys) it has access to (meaning it has a corresponding private key). Thus we can't tell ssh all the keys we have because that would be an information leak and may also take too long. Because the user may in some cases not want to use the ssh-agent but resort to ssh command line input of the passphrase, we do not insist on using a key known by gpg-agent.

Perl would be okay for maintainer mode but not for regular builds. The reason is that perl is already used by autotools but a build shall still be possible w/o perl.

I'm looking into doing a pretty epic hack of using the switch_endian syscall to speed this up.

I don't know. That would make it a relatively easy transplant. We've also used the Cryptogams code as a reference for Golang enhancements, if that helps. I'd welcome guidance on the matter from a maintainer.

Would the maintainers accept having perl in the repository? Linux does it.[1]

FWIW, I disabled @aa7356 because he again started to troll.

Snap question regards to the clock;

Sorry, I can't parse that. For development question please use gnupg-devel at gnupg.org.

Feature supported in master.

Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)

Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.

In T4515#125651, @aheinecke wrote:

Hi,

What client does your colleague use so that you have to use PGP/Inline?

That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned

Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.

I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.

Anyway, thanks for your feedback. It is always valuable to know what users would like to have.

Best Regards,
Andre

What client does your colleague use so that you have to use PGP/Inline?