Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break.
Dec 7 2020
Oct 16 2020
@werner , if you would like some help moderating this bug tracker, I don't mind volunteering to do it.
Sep 16 2020
Sep 15 2020
Aug 31 2020
There is not a lot of demand for this, thus we have not continued to think about it.
@gniibe: We could implement this on the card by extending our ugly hacks on the login-data DO, which are currently:Everything up to a LF is considered a mailbox or account name. If the first LF is followed by DC4 (0x14) control sequence are expected up to the next LF. Control sequences are separated by FS (0x18) and consist of key=value pairs. There are two keys defined: F=<flags> Where FLAGS is a plain hexadecimal number representing flag values. The lsb is here the rightmost bit. Defined flags bits are: Bit 0 = CHV1 and CHV2 are not synchronized Bit 1 = CHV2 has been set to the default PIN of "123456" (this implies that bit 0 is also set). P=<pinpad-request> Where PINPAD_REQUEST is in the format of: <n> or <n>,<m>. N for user PIN, M for admin PIN. If M is missing it means M=N. 0 means to force not to use pinpad.
A new 'C' flag maybe?
@werner , I understand your poiont.
So, the best approach would be:
(1) Define some DO (Data-Object) or attribute/flag per key to control timeout or "force" by the card itself.
(2) Modify scdaemon so that it always ask authentication state to the card before doing crypto operation.
(3) Modify gpg frontend so that it shows those attribute/flag and setup.
Then, it is the card itself to control timeout or "force".