Will be in 2.4.2

In current Kontact and now also in Kleopatra, by default, it's 30 days for own certificates and 14 days for all other certificates (including certificates in issuer chains), but Kleopatra currently doesn't notify the user about expiring issuer certificates.

The default time period for warning about pubkey expiration is 14 days in the old Kontact (IIRC).

Good timing. We have just added the necessary bits to the shared libkleopatra. They just need to be used in GpgOL. See T6330: Kleopatra: Additional Expiry handling.

The generate keys etc. actions in the keys part of the view are debatable. At least for VSD I think they should not be shown or greyed out for not VS-NfD compliant cards -> see T6786
(I think there were even algorithms offered for generation on card which would result in an error, but I won't investigate further at the moment.)

I will re-test it with KDE neon.

@dvratil I think the message has changed a bit with recent versions of the WKS server. Or is this maybe in a plugin that might not be installed on some distributions? At least when alexk tried it it was not processed on a fairly recent ArchLinux but he had such issues like plugin for crypto settings in KAdressbook not installed etc. so it might just be that. I can test this again but its probably best if we get you a test mail address with a forward for gnupg.org (which has WKS)

From https://phabricator.kde.org/D3140 the "Confirm your key registration" (see last screenshot) button seems to be what this is about, right?

I have yet to test this, but just by looking at the code in kdepim-addons this seems to already be implemented since the beginning. When we were implementing this back in 2016, we were using some testing WKD server that @aheinecke operated (the presence of testuser10@test.gnug.org and key-submissions@test.gnupg.org keys in my Kleopatra is most likely from that time and instance).

Fixed in 1.10.2.

Fixed in 1.10.2.

The crypto profiles have been removed in Gpg4win 4.1.1

In T6445#169394, @werner wrote:

Indeed, this is not implemented. AFAIK, this feature was introduced by PGP 2 to support BBS systems. I would suggest that you use binary messages and implement the chunking at the application level.

Indeed, this is not implemented. AFAIK, this feature was introduced by PGP 2 to support BBS systems. I would suggest that you use binary messages and implement the chunking at the application level.

I'll add new error codes to gpgrt

You could configure gpgme with

Any volunteers to write a manual? ;-)

The flag has been implemented in 2.4 but as long as this version has no approval it does not make sense to do anything more. Let's re-open this task if we have a real request for this.

Here's mirroring script that is in place currently:

#!/bin/bash -e

@jukivili was so kind and does the mirroring now.

gpg-agent now supports READKEY --card command which creates stub file when it's not yet available on host computer.
It was implemented by rG82cbab906a3e: agent: Add --card option for READKEY.

Yes, --export creates the OpenPGP specified format.

We stopped maintaining GPA in favor of Kleopatra.

I mean what gpg --export gives Werner.

Do you mean the pubring.gpg format or the on-wire OpenPGP format; ie. what gpg --export gives?

Not if there are technical reasons to keep the address. BTW, you solution would not help because the fingerprint of key is personal data in the same way as a mail address.

Werner, according to GDPR if a user upload a key with it's name and email address he or she may be able in the future, to ask for removal of this information.
How is this going to happen, to a keyserver, accordingly to your suggestions?

Will go into 1.19.0

A tool can't make some thing GDPR compliant - this is all about policy and informed choice. There is actually no problem if you allow ppl to decide whether to upload personal information to a public service.

I changed the title of the issue to make it about adding the warning. I also think that is a good idea to avoid confusion / accidents.

Seeing that there are "groups" in Kleopatra, I read the docs, and they suggested that the groups are for addressing multiple recipients.

Settings -> Configure Groups.

Thank you.
Applied to both (master and 1.10).

This pretty much highlights a general problem of groups: If the distribution groups for the email client are managed independently from the certificate groups then there will inevitably be discrepancies. The obvious solution is the usage of groups managed by a central service for email addresses and certificates. (Or an encrypted mailing list service.)

Right, thanks for the review! Updated patches below.

Actually, the same issue is in the mac case, which I missed on first couple of reviews:

-  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);
+  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_mac_algos);

Going through the code once more, there is one typo to be fixed:

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);

should say

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_md_algos);

otherwise ack.

That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.

@werner Seeing as you seem to be actively maintaining this project: is there any way to move this forward? This is breaking quite a few builds of development environments for my company and we are now applying similar patches ourselves but it would be nice to get this merged upstream.