I located the cause; Current implementation cannot parse the data like:

2611:d=5  hl=4 l=1632 cons:      cont [ 0 ]        
2615:d=6  hl=4 l= 500 prim:       OCTET STRING
3119:d=6  hl=4 l=1124 prim:       OCTET STRING

Ack from me for new 0005 and 0006.

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

Possibly, it could be done with pam_exec http://linux-pam.org/Linux-PAM-html/sag-pam_exec.html
developing a simple executable (or even small shell script).

Great. No problem for me.

No problem. Both patches look good.

In TLS 1.2, it refers RFC5116. In RFC5116, it says:

My reading was wrong; Indeed we use memcpy from out_ctr. But it increments in network byte order.
So, for AES-GCM, it works well.

Patches look good for me.
Please go ahead.

It was the bug of generating AEAD packet, which does:

Sorry for pushing immature fix. I located the cause, but I didn't have enough concentration for fix.

My direct problem is to silence warnings for newer GCC.

Thank you for your suggestion.

I simplified the script not to use cmp: rC3c8b6c4a9cad: fips: Fix gen-note-integrity.sh script not to use cmp utility.
And I clarified the semantics of the integrity check.

I located the cause:

../../src/gen-note-integrity.sh: line 78: cmp: command not found

I pushed the change: rCa340e9803882: fips: More portable integrity check.
It uses .note.fdo.integrity section, not loaded onto memory.
It simplifies the logic, and switches to dladdr (from dladdr1).

Pushed the change which fixes the build with ld.gold.
rC9dcf9305962b: fips: Integrity check improvement, with only loadable segments.

Thank you for your suggestions, @werner.
I agree that we should not put much effort to develop our own methodology here; Too much effort may introduce possibility of unmaintainable code, which should be avoided for the particular purpose of "integrity".

I am going to apply https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/64ccc25c4b4a2c8c4e13e7e37ff1c8c60a3d8401
And consider adding the code to limit hashing content (from start of the file to end of data section).

Good to hear the cause.

It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.

Instead, let us remove the feature.

FYI, if you can use backports, GnuPG 2.2 series is available
See : https://backports.debian.org/news/stretch-backports/

Sorry, I looked wrong place. It is balloon_final which assumes user provided RESULT is aligned, which is wrong.

I think that this patch should not be needed, if our implementation of _gcry_private_malloc is not buggy (ensuring same alignment condition as system malloc does).
I just realized that it is buggy unfortunately, so, I'm opening a task for that.

Tested on a big endian machine.

$ uname -a
Linux perotto 5.15.0-2-powerpc64 #1 SMP Debian 5.15.5-2 (2021-12-18) ppc64 GNU/Linux

FYI: When you have a problem with pinentry, possible workaround is using gpg with --pinentry-mode=loopback, which redirects pinentry queries to the caller (instead of invoking pinentry session).

Thank you for the debug information.

Done by rGc8cd66ae7e60: m4: Update our library m4 files from master.

The change of pinentry-tty rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks. fixes SEGV, but the problem of your case is that access to the device file (/dev/pts/2 in the case of your log with pinentry-tty) failed.

Thank you for your debugging.