Poldi (no-)change

NIIBE Yutaka gniibe at fsij.org
Mon Sep 2 01:58:48 CEST 2019


I maintain Poldi in Debian, as a package maintainer, because it would
be useful in some situation.

In private mail, I was asked about Poldi in the context of this bug (of


Since it is better to discuss in public, I bring it here.

In the past, similar bug is reported with SDDM.  It was reported to
gnupg-devel with a proposed patch for Poldi:


But, the proposed patch (which removes conversation upcall from Poldi)
doesn't work well for other valid use case (of lightdm).  So, it was not

In my opinion, it is wrong to change Poldi to work around for this kind
of bug.

This time, I investigated the cause in detail (in my environment).
For mine (I use Debian), and the relevant code is:

    The executable kcheckpass:


    The greeter (for GUI):

The kcheckpass does it correctly (handling "conv"ersation between PAM

IIUC, it is the greeter which is need to be fixed.

The password is only set once at tryUnlock function at first, and the
function which handles conversation between PAM module repeatedly
returns this same password by handleVerify function (forever), without
asking to a user at all.  This implementation only works when a PAM
module does no upcall.

Te elaborate...

The greeter only implements PAM support partially which only works well
in a specific situation; It only works when the first pass goes well.
It doesn't work well when PAM module asks the second pass (or more) with
conversation feature.

Here is a figure to explain interaction.

A user of a PAM module                   A PAM module
(greeter+kcheckpass)                     (libpam-poldi)

(1) Simplest case: only with the first pass

-->With a PIN from human user

        Ask authenticate -->

                         <--    PAM_SUCCESS

Good, it works.

(2) General case(s): multiple passes

        Ask authenticate -->


                         <--    Up call by PAM_CONV
                                for new PIN
                                with a message of error (PIN too short)

<-- should ask human user again
--> new PIN

   it answers back with new PIN -->

                        go again if a PAM module asks PAM_CONV again

                        Or, finally it comes with:

                         <--    PAM_SUCCESS


                         <--    PAM_AUTH_ERR

The greeter never implements the case of (2) correctly:


Here, it returns back with same string by GSendStr, without asking new
PIN to human.

More information about the Gnupg-devel mailing list