When scd random command is issued via gpg-connect agent, output does not match expected value.
E.g.:
nephirus@soridormi:~$ gpg-connect-agent --hex 'scd random 32' /bye D[0000] D0 AB 10 07 2E 10 4A A0 1C 3B 5F E9 10 79 36 81 ......J..;_..y6. D[0010] 00 62 E8 F5 25 30 41 70 92 85 EA B3 6E B2 1C 60 .b..%0Ap....n..` D[0020] CB 0E .. OK
We can see that length is off by 2 bytes. Further inspection of scdaemon log shows that byte 0x0A got escaped to string "%0A", which was turned into 0x25 0x30 0x41 in the output.
scd.log snippet:
2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: dwLength ..........: 34 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: bSlot .............: 0 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: bSeq ..............: 28 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: bStatus ...........: 0 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: [0010] D0 AB 10 07 2E 10 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: [0016] 4A A0 1C 3B 5F E9 10 79 36 81 00 62 E8 F5 0A 70 2019-12-16 12:59:44 scdaemon[5887] DBG: ccid-driver: [0032] 92 85 EA B3 6E B2 1C 60 CB 0E 90 00 2019-12-16 12:59:44 scdaemon[5887] DBG: response: sw=9000 datalen=32
FWIW, 0x0A is not the only value that is being parsed wrong. I've had same issues with 0x0D and 0x25.
Bug is present even without --hex parameter:
nephirus@soridormi:~$ gpg-connect-agent 'scd random 32' /bye |xxd 00000000: 4420 3c3a dcd9 eedd 3bc7 849d 2e41 7948 D <:....;....AyH 00000010: 8556 f9c2 5f21 c933 de67 8f7f 2154 3d25 .V.._!.3.g..!T=% 00000020: 3041 c825 3041 0a4f 4b0a 0A.%0A.OK.