Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.

For me this does work also when decrypting:

btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

https://invent.kde.org/pim/messagelib/-/commit/f8373bc09b228cc88577ec88b285c58a06122575

Let's schedule that for 2.6

See rG0988e49c45 which implements time and group but not yet the split thing because we are not shure that is good idea to have this w/o any implementation support.

secring.gpg is only used by unsupported legacy versions of GnuPG. Since 2.1 it is not anymore used.

So if I have \MyDirectory\pubring.pgp and MyDirectory\secring.pgp files, how do I use the --homedir option to access those?

This is not really what the issue here is talking about. This issue was about "merging" multiple keyrings into a single view. If I understand you correctly you want to have matching pubrings and secret key directories for different applications. That is fully covered and what many users do by setting GNUPGHOME through the environment, the --homedir option or the windows registry.

Did anything get implemented to handle this? We have a central network file share where we store our public and secret key rings. We have several different applications that access these key rings. I'm trying to convert one of them from using gpg.exe via the command line with the --keyring and --secret-keyring paramters to using gpgme, but I don't see a way to specify the keyrings. Any help would be appreciated.

Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.

Was resolved, see T4457

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.