Hi, gpg4o does not send PGP/MIME (the proper format for including attachments and no encoding problems). As such it does not have the Problem described here. You can use "Send PGP Mails without attachments as PGP/Inline" in the options of GpgOL to have something similar. This will also work for Kopano.

how is the actual state of this point? Is it solved?

I don't think that GnuPG >= 2 can still be build with RISCOS. In any case it is such a minor platform that we are removing special RISCOS hacks when touching such code parts.

Done.

This entry was created based on the conversation at #gnupg channel.
I can't reproduce keep hanging.
I confirmed that pinentry vanished (perhaps, because of timeout).

Apple Clang changes the -fno-common to be default. It can also compile by adding -fcommon to the CFLAGS but I suspect this patch (with the exception of adding __APPLE__ to the (defined (__riscos__) || defined (__APPLE__))) would be needed for things to work properly on __riscos__ also.

-fcommon, -fno-common
       This flag specifies that variables without initializers get common linkage.  It can be disabled with -fno-common.

A workaround for this until the HTTP client is fixed is to just use curl instead:

Do you say that the linker can't handle the standard common block feature? The only toolchain I am aware of which does not understand this is the Norcraft C compiler for RISC OS. And now also Clang building for iOS?

I am running into the same exact issue. It seems that dirmng is incorrectly attempting to resolve the addresses for the keyservers despite having been given an HTTP proxy to connect through.

gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.

We are moving to use the yat2m from gpgrt (libgpg-error); thus the additional tag.

I've updated the README and added example mainifests.
Make dist is also updated I could build the extension and webpack it from the dist package.

Hi,
Can I ask if there is any update on the issue that I face?

Thanks for your answer

Ok
Thanks for your answer

I'm not sure that I understand your Problem. It might be helpful if you could provide screenshots of your problem so that we can better understand it.

We are not a CA and do not provide certificates.

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?