It turned out that my pinentry reported "fully canceled" on Cancel (see T6491: Pinentry-Qt: Password prompt for each subkey if password change is cancelled) which made gpg output nothing.

Tested and works now for me as expected. Thanks.

The original reporter mentioned that this only occurs when called from kleo. But let me recheck.

Also done for 2.2.

This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

gpg --export-secret-subkeys --armor 704769B8D5C15319A27C74BBB47052506607DA6E confirms that gpg 2.4.1-beta21 outputs nothing if the password entry is canceled.

Of course, it's about right clicking the encryption subkey. That's what I tested. Anyway, cancel wasn't handled properly. Now it is.

In T5755#172514, @ikloecker wrote:

I cannot reproduce the problem with Cancel. When I try this, I get the error "The result of the export is empty." and nothing is written to disk. I'm using GnuPG 2.4.

Anyway, handling of cancel was indeed missing.

The expiry checker checks for expiry. It doesn't and shouldn't do anything else.

I cannot reproduce the problem with Cancel. When I try this, I get the error "The result of the export is empty." and nothing is written to disk. I'm using GnuPG 2.4.

Another request for this would be that the for expired keys a --locate-key might be triggered. GpgOL currently does this in internal logic and this causes GnuPG to refetch the key e.g. from WKD if the key came originally from WKD. https://bugs.kde.org/show_bug.cgi?id=471911 I am not sure if the expiry checker already does this, but someone pointed me to the KDE bug and I will point back here because it makes little sense to fix this in the kmail resolver when we want to replace it.

This has a serious usability issue. If you cancel the password entry when exporting it reports success and creates an apparently valid secret key file but without the subkey you intended to export. So worst case the user thinks he has a backup but instead has no backup :/

The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.

Remaining places are:

• common/sysutil.c debug output to format HANDLE --> T6597
• common/sysutil.c iobuf_get_fd and its use cases --> T6580
• agent, kbx, scdaemon, dirmngr: socket and FD2INT/INT2FD --> T6598

works

Except a case, all use cases of translate_sys2libc_fd_int is with a result of integer from command line argument.

Changes are pushed.

We need to keep the gpgtar part of commit in rG2756147e392c: gpg,sm,tools: Use string for option --*-fd..

The changes are intrusive to other implementations (POSIX and Windows 32-bit).
So, I revert the changes of replacing translate_sys2libc_fd_int.

I don't argue about the technical necessity for the change. I agree the fact it works (without such changes).

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Fixed in master.

See for T6545 for a new request to support IDP.

We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.

The use cases are:

• oPassphraseFD for gpgsm, gpg
• oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
• oLoggerFD for gpgsm, gpg, gpgv
• oAttributeFD for gpg
• oCommandFD for gpg
• oOverrideSessionKeyFD for gpg

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

Nah, the description for that extension is pretty strict and I won't feel comfortable to just ignore it. BTW there is also T6398 (nameConstraints) which needs support. But for debugging a ignore extension makes sense.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Yeah no progress for files larger then 32 bit o.O... But this used to work 😭

On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t

Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368

Yeah, probably a Windows/MinGW 32-bit problem. GpgME::Data does

off_t size = seek(0, SEEK_END);
seek(0, SEEK_SET);
std::string sizestr = std::to_string(size);
// Ignore errors as this is optional
gpgme_data_set_flag(d->data, "size-hint", sizestr.c_str());

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.

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.