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).
> 
> 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.

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.

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.