On 2019-09-27 14:11, Franklin, Jason wrote:
Dear Maintainer,I am contacting you directly because my bug report and subsequent follow-up post have not yet received a response. This email is with regards to the following bug report and patch:
bug - https://bugs.debian.org/934185 patch - https://phabricator.kde.org/D23849
I worked to produce the patch, and the change has been includedupstream. The patch for the "libkscreenlocker5" Debian stable package isattached.
I earnestly request that you apply the patch and upload the changes to the Debian repository. Adding this change will fix a fairly nasty bug with the conversation between Poldi and the screen locker.
Thanks for working on this. As reported the issue seems to be specific to a particular type of smartcard device, but the patch seems to be a bit more general than that, so I guess it's worth the stable upload. To do so, we'll need to explain the stable release team the rationale of the patch and give them pointer so the review is possible without having a background on how the kscreenlocker and kcheckpass interact. I would prefer if you could explain some of the patch parts, in particular the ones that the commit message assumes some background.
In particular, the fallthrough ends up calling the same code on abort and on ready, which sets the m_ready variable and sends a USR1 signal on direct mode, what's the idea here? This ends up with one or two USR1 signals being sent to kcheckpass, can you please explain why is this needed so that kcheckpass lets pam process the smartcard input?
Also the changes in kcheckpass_pam.c could do with an explanation on why is that the PAM_data.abort needed to be zeroed. Finally, previously, the pam_error was hidden and pam_end was called with PAM_SUCCESS, was that wrong?
Happy hacking, -- Saludos /\/\ /\ >< `/
signature.asc
Description: OpenPGP digital signature
