[2026-03-26 17:16] "Omar Polo" <op@omarpolo.com>
> Martijn van Duren <openbsd+tech@list.imperialat.at> wrote:
> > On 3/21/26 18:14, Omar Polo wrote:
> > > Hello tech,
> > > 
> > > some time ago we've introduced a K_AUTH table lookup method, to offload
> > > the authentication handling to a proc table.  This is different from the
> > > previous credentials tables because they are supposed to return the hash
> > > of a password for the given user.
> > > 
> > > The only problem with this is that we have a lowercase() before reaching
> > > the table itself, so for K_AUTH we end up lowercasing both the username
> > > and the password.
> > > 
> > > The cautious reader will realize that this will leave also the username
> > > with the original casing.  I'm a bit unsure about what to do.  For
> > > K_AUTH the caller code will construct a string "username:password"
> > > without changing the casing, then calls table_lookup().  Being pedantic,
> > > the username *could* be case-sensitive, so there's a small argument for
> > > keeping the case as-is.
> > > 
> > > okay?
> > > From a quick look through the opensmtpd-tables in ports, I'm unable to
> > find support for K_AUTH in any of them. And if there are tables out in
> > the wild who support this I would have expected someone to shout that
> > their users can't login (or someone needs to reconsider their password
> > policy if none of their users have an upper case in their password).

Several users have requested auth support for ldap. The report about
K_AUTH is not implemented correct is from end 2024. There were severel
proposals to change the table-proc, table-ldap and the openbsd
ldap-server to allow auth with ldap, all before the table protocol
changed. The initial report for errata 026 was from someone playing
around with K_AUTH. So there are definitive users for K_AUTH.

> > Considering the above I would suggest to remove K_AUTH entirely, instead
> > of adding more tentacles. If we want auth offloading at some point a
> > better API might be considered, but I reckon simply catting username and
> > password with a ':' isn't the most convenient for a consumer. Maybe
> > something like a challenge-response interface to allow for more SASL
> > mechanisms might be a better option.

A protocoll which also would allow SASL would be nice, but I doubt this
will happen in the next 5 years. After that we also need time to
implement it in the tables. It might also be usefull to first make
table-proc nonblocking. But this is not that easy, so having a working
api allows to improve smtpd and the tables in paralel.

From my perspective it looks like the remove is suggested because I was
to slow implementing the counterpart. What makes this even more
frustrating: There are several patches which only wait for decicions by
obenbsd. Btw. my aldap patch from over two years is still not commited.

> I'm not sure.  I remembered that we added this for table-ldap which, to
> be fair, it's a table that I'm comfortable touching :P
>
> I knew that philipp wanted to use this, so I'd wait before removing this
> feature; I'd prefer to give them more time to play with it in their ldap
> context, and then eventually remove it, or add an extra "sasl-like"
> interface.

Yes I have a plan to implement this for table-ldap, Not because I personaly
want to use it, but more to finish what I have started.

> but i'm not strongly opposing the removal either.  I just don't think
> it's a big deal to fix it, get more feedback, and then reiterate.

I am strongly opposing the removal as long as there is no alteranitv
availibel.

Philipp