Re: [dev] [slock] Compile-Time Pluggable Authentication Code (passwd, pam, etc.)

From: Sebastian J. Bronner <waschtl_AT_sbronner.com>
Date: Mon, 7 Oct 2024 20:18:52 +0200

Hi Laslo,

> > Also think
> > about providing a better abstraction, e.g. a possibility for the
> > backends to have a void 'state' pointer that they can set up during
> > initialisation. In this way, the passwd backend could store the entered
> > password in this state (which might as well also be a full custom
> > struct), and you save yourself from abstracting the input of characters
> > through the auth-API.
> >
> > Going even further, maybe the best approach would be to have a
> > well-defined event interface. Anyway, just keep it as simple as
> > possible!
>
> This is a point I will gladly revisit. I'll get back to you on this.

I spent the weekend considering how to improve the abstraction. Better
in my mind means more generic while keeping it reasonably simple.

But everything I come up with adds both run-time as well as code
complexity. As it stands, I am abstracting backend state using pointers
to opaque structs that the backend can initialize and use as it needs
(state->auth and state->wio->auth). This is like your idea of a void
pointer, but without the need for casts.

As far as what procedure should store the password, I believe that a
general input function in the main slock module is best. The reasons are
(1) it can be reused by any backend desiring keyboard input, (2) it can
direct screen state in a uniform way, independently of the backend in
use, (3) it keeps the backend slim, just sticking to its core
functionality of authentication methods and authentication-related
feedback, and (4) that way the handling of sensitive input data can be
analyzed and verified in one place.

Or did I miss where you were going?

Kind regards,
Sebastian
Received on Mon Oct 07 2024 - 20:18:52 CEST