Bug#1117638: Bug#1117720: Bug#1117638: openssh-client 10.1p1-1 fails to read smart card
Colin Watson <[email protected]> Sun, 12 Oct 2025 23:53:31 +0100
| Newsgroups | gmane.linux.debian.devel.ssh |
|---|---|
| Message-ID | <aOwxa4JkHQX4XdLc__47655.7402334706$1760309725$gmane$org@riva.ucam.org> |
On Mon, Oct 13, 2025 at 12:20:25AM +0200, Jan Nordholz wrote: >my TL;DR analysis: > >* in 10.1 and up, ssh.c calls pkcs11_init(!options.batch_mode) which is > intended to set interactive mode, but that ends up in the NOP implementation > in ssh-pkcs11-client.c. That same file also contains a "proxy stub" > implementation of pkcs11_add_provider(), which causes the new pkcs11 helper > process to be forked off, which itself then calls the "real" > pkcs11_add_provider(), but always does pkcs11_init(0) first. So we have > "interactive = 1" in the parent, but "interactive = 0" in the helper. > >* in 10.0, ssh-pkcs11-helper was not yet used, and the ssh client called > pkcs11_init() and pkcs11_add_provider() from ssh-pkcs11.c directly, which > caused the "interactive" flag to be set to the correct value. > >I've now made a patch that plumbs through the "interactive" flag from the >parent ssh process to the pkcs11 helper. It's not a stylistic marvel, but >neither is the duplication of function names in the upstream source. ;) >I hope nobody ever links the wrong object files together... > >Patch attached, feel free to forward upstream. Thanks for the analysis and patch. It sounds plausible, but it's really not something I'm in a position to review myself as I hardly know this code at all. Is it really impossible for you to send it directly upstream yourself? It's always better if people can do that, since then they can discuss it with upstream directly rather than me having to relay everything back and forward. If creating a bugzilla.mindrot.org is a complete deal-breaker, then you can probably send the patch to the upstream mailing list instead: https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Thanks,