Thanks for the patches. I have completely rewritten FindAssuan2.cmake and have added a separate FindGpgError.cmake. We cannot assume that pkg-config is available everywhere. Therefore, we cannot use pkg_check_modules exclusively. I have verified that the Find*.cmake files work for gpg4win and for the AppImage.

@raysatiro: Please re-open if you are able to give us a reproducer

Fixed. Shall we backport this to gnupg22 ?

Hello ...

It is not really helpful if you publish that fact anyway on a public tracker.

We sometimes grant our customers the privilege of receiving updates a few days earlier than the community. It is not really helpful if you publish that fact anyway on a public tracker. BTW, there is no community version gpg4win 3.1.26.

Fix for 2.4 is rG2aacd843ad

Thank you for your reply! I'll modify my testcase

I figured out the situation.

Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.

Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.

works

Thanks. Commited to master.

When I look at the stack information, I find that because E->p is not assigned in the function mpi_ec_get_elliptic_curve(), this produces a null pointer，but it didn't get to the branch : if (errc) goto leave;

If you pass NULL to that function, the calling code is wrong. No need for an explicit check in nomralize - check should be done in the public API (if at all).

I tried to fix the segmentation fault, so I added a null pointer check at the end to protect it.

Here is my try of next, after 0001.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

Regarding armored files: Well the whole point of armoring is that there is only a plain 7-bit ASCII channel.