When we will actually extend the fingerprints, more changes (spec and implementation) will be required because of the length limitation of DO 0x6E.
See https://dev.gnupg.org/T4097

Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.

In master, commit from rGce2f71760155: g10: Change decryption key selection for public key encryption. until rG84cc55880a58: g10: Prefer to available card keys for decryption. fixed this.

I think it's good to close this as "resolved", since many fixes have been done, and I don't have remaining issue.
@wiz Please open another ticket for your next try.

Okay, can you please provide sample data for the test suite? Best using one of the existing keys but adding another one won't harm either.

DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.

No response so closing as invalid.

What are we going to do with this report? The last comment is 6 months old; can we change from testing to resolved or do we need to wait for a gpgme release?

I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.

@kallisti5: For you server you can add only_urandom to random.conf when changing to a multiuser runlevel and remove it early at startup and termination.

/dev/random, RDRAND, etc involves a lot of political arguments and thus it is not easy to decide what to do. What you are calling for is a linux kernel specific code path (note that rndlinux is used by most Unices) and won't be helpful for other OSes. I am of course willing to do add specific for for a few widespread OSes (and in any case for Debian). It is a major change and thus does not belong into 1.8 - I am fine with master which Debian might want to backport.

Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.

What are your use cases?

Well, Werner is just back so he can say more.
An excellent reviewer was Stephan Müller from atsec. He is also involved a bit afaik in the kernel random development.

@aheinecke thanks for the followup!

I'm not sure if it's exactly the same case, but:

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.