Ok! If outlook shows it we should verify it.

Hi Andre!

The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Backport done for 2.2.10

With -beta24 the crash on send should also be gone. I've removed the option for the workaround as I expect that it is no longer necessary. (Yeah I'm an Optimist :-P )

AFAICS this is now implemented. We have the option --with-key-origin and even support in GPGME.

Without KEYLIST_MODE_WKD I also can't implement the desired behavior in a MUA using GnuPG.

Why the restriction to keyorg wkd ?

Done. To be released with 2.2.10.

FWIW, we record the origin of the keys. So you have the information. Use --with-key-origin in a key listing. GPGME also has the info.

T4026 is a bit related. I'm suprised that the signature check for mailman mails works at all for you ;-)

Thanks for the input. GpgOL should check against what outlook shows as the "From" Address. In your case: What does Outlook show? Is it "info@example.org" or "puppets-bounces" ?

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: