| Summary: | Lock screen showing PKCS#11 error and referring to smart cards and fingerprint when neither have been set up | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | sreeharisreedev1 |
| Component: | Screen locking | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CLOSED DOWNSTREAM | ||
| Severity: | normal | CC: | bugs.kde.org, kde, nate |
| Priority: | NOR | Keywords: | qt6 |
| Version First Reported In: | 6.2.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
sreeharisreedev1
2024-01-17 23:23:33 UTC
This is very likely caused by a packaging issue, as there are rather specific requirements for the lock screen in Plasma 6. I'd recommend that you check out https://community.kde.org/Plasma/Plasma_6.0_Release_notes#New_required_PAM_configuration and either verify yourself that everything was done right, or else contact the packagers of the Plasma 6 releases in your distro. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! This is a problem in Kubuntu 24.10. /etc/pam.d/kde does not exist.
That said these messages are both poorly designed and not configurable in settings, as far as I can see.
And, I don't seem to have anything in /etc/pam.d saying that I _do_ have a fingerprint reader or smart card. In the absence of configuration, these messages shouldn't show.
> ls /etc/pam.d/
chfn common-account common-session cups other runuser sddm su su-l
chpasswd common-auth common-session-noninteractive login passwd runuser-l sddm-autologin sudo xpra
chsh common-password cron newusers ppp samba sddm-greeter sudo-i
My comment of "This is very likely caused by a packaging issue" remains true for the issue you're seeing. Please contact the Kubuntu folks. @Nate I addressed that in the second part of my comment. Smart cards and fingerprinter readers are niche hardware. It's a bug for these ugly messages to show in the absence of configuration stating that they exist. (In reply to Reuben from comment #6) > @Nate I addressed that in the second part of my comment. > > Smart cards and fingerprinter readers are niche hardware. It's a bug for > these ugly messages to show in the absence of configuration stating that > they exist. Having looked into the source of this problem I don’t see any reasonable way for KDE to do anything about this. kscreenlocker6 needs PAM to actually load the correct service so it can query to see if it is available. Instead, PAM silently falls back to the default service ("other") when the requested service does not exist. This means when KDE thinks it is checking for smartcard/fingerprint support, it is actually checking for "other"-authentication support, because PAM is lying about what service it loaded. I’m not seeing anything in the PAM API that would allow a caller to learn that this has happened or to prevent it from happening. So, the distribution simply needs to include the appropriate PAM service files. Sorry, but I question the "resolved downstream" status. a) Have Kubuntu in fact resolved it? I don't see evidence of that, but great if they have. b) What percentage of KDE installs come through Kubuntu? ALL of these users are probably still affected. c) The new settings/verbiage/feature is KDE initiated. If your distributers mess up the packaging, and you can't control the distributers, KDE can withdraw the feature, or move it behind a setting in order to make it right for users. I know you hate adding settings, but what's worse: a sizable percentage of your users encountering a "KDE bug" or a setting for the probably sub 1% of users who have fingerprint or smartcard auth hardware? The setting could even be enabled by a wizard after the first login if you detect that this hardware exists. d) Finally, to expand on the above more generally, if your distributers are leading to your software "having bugs" and can't be relied upon to package KDE "properly" or "optimally", then set up a certification program. If Ubuntu loses "KDE Certified" status on Kubuntu, they'll either stop shipping the variant or throw some more resources at it to gain and keep certification. KDE is the brand that matters to most of your users; they just want a reliable OS underneath it, which is why Kubuntu has a sizable share, since traditionally Ubuntu has been quite reliable. I'd recommend reading https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean. If this is a common pitfall for distros to get wrong, the way to do it properly should be added to https://community.kde.org/Distributions/Packaging_Recommendations. I can't do that since I don't understand the issue well enough to be confident in anything I could write there. Someone else who feels they have a good grasp of the issue should feel free to do so! If we formalized this with some kind of certification program, perhaps by consulting the aforementioned wiki page, 0% of distros would pass. It's just the world we live in, unfortunately. (In reply to Nate Graham from comment #9) > If this is a common pitfall for distros to get wrong, the way to do it > properly should be added to > https://community.kde.org/Distributions/Packaging_Recommendations. I can't > do that since I don't understand the issue well enough to be confident in > anything I could write there. Someone else who feels they have a good grasp > of the issue should feel free to do so! It looks like the information at https://community.kde.org/Plasma/Plasma_6.0_Release_notes#New_required_PAM_configuration did not make it to the packaging recommendations page. Indeed not. Unfortunately I don't understand PAM well enough to be able to write anything I'd have confidence about appearing on that page. Someone else will need to. |