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.

(my example cert is 0x09BB0EEE)

Added SETQUALITYBAR support with some fixes for glitches when an error string was set. Wide characters seem to work OK.

We came to the same conclusion -- the SHAKE digests are not usable for sign/verify operations the way how it is implemented now. But it would be more clear if we would have explicit allow-list.

After consulting with our certs lab and studying the code I think SHAKE should not be a problem for now. All of the _gcry_digest_spec_shakeXXX seem to neither have an mdlen nor a read() function. pk_sign and pk_verify seem to both call md_read() which should fail because of the missing read function, kdf checks _gcry_md_get_algo_dlen() which should also disallow SHAKE.

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

Good catch. A similar problem might arise with SHA384 according to section D.R which states

One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:

These look good to me.

Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:

This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.

Added curses-repeat branch which needs testing for wide chars and other stuff in case i missed something