Bug 3058

Summary: ssh should not complain about "no slots" when PKCS11Provider is specified, but no slot is found nor used
Product: Portable OpenSSH Reporter: Jakub Jelen <jjelen>
Component: SmartcardAssignee: Damien Miller <djm>
Status: CLOSED FIXED    
Severity: enhancement CC: djm, dtucker, jcpunk, unassigned-bugs
Priority: P5 Keywords: pkcs11
Version: 8.0p1   
Hardware: Other   
OS: Linux   
Bug Depends on: 2610    
Bug Blocks: 2988    
Attachments:
Description Flags
downgrade from INFO to DEBUG loglevel dtucker: ok+

Description Jakub Jelen 2019-08-23 19:20:04 AEST 
This got back with OpenSSH 8.0 and variant of this message is again printed as an error, which is irritating.

+++ This bug was initially created as a clone of Bug #2610 +++

Specifying a PKCS11Provider in the configuration and using the ssh without a card inserted results in the error

    no slots

during the pkcs11 initialization. This error is in no way fatal and usually does not require user attention. We might argue that that the user should configure this option only when it is absolutely needed using proper match blocks, but even though the verbosity is too high and without any context does not make much sense.

Also other messages informing about "provider already registered" and about "no keys" are not too important to show as error() form my point of view. Also in most of these logging functions, there is missing context and the user does not have the slightest idea where does these messages come from and what do they mean. Prefixing them with the function name also seems like reasonable idea.
Comment 1 Damien Miller 2019-08-30 13:20:07 AEST 
Created attachment 3314 [details]
downgrade from INFO to DEBUG loglevel

I presume this is the message you're referring to? Maybe it should be verbose() instead of debug()...
Comment 2 Jakub Jelen 2019-08-30 17:00:35 AEST 
Thank you.

I think verbose() would be better, since this message ads some value when you want to dig into that deeper, but is for no good use in default operations. But debug() is fine too.
Comment 3 Damien Miller 2019-09-02 10:20:02 AEST 
applied - thanks
Comment 4 Damien Miller 2021-04-23 15:10:00 AEST 
closing resolved bugs as of 8.6p1 release