[tpop3d-discuss] APOP from flat files

[Chris Lightfoot]

On Tue, Feb 04, 2003 at 11:41:19PM +0000, Paul Makepeace wrote:
> On Tue, Feb 04, 2003 at 08:45:49PM +0000, Chris Lightfoot wrote:
> > On Tue, Feb 04, 2003 at 08:29:17PM +0000, Paul Makepeace wrote:
> > > Perhaps I'm being dense, but is this possible? Are people only using
> > > APOP with MySQL/perl/other?
> 
> Still wondering here - what are the data sources available for those
> wanting APOP?

No, you're correct: there's no support in any of the other
authenticators. There's an example auth-other script in
scripts/ to allow individual UNIX users to authenticate
against a password ~/.mailauth or similar.

> > > I was thinking of patching out fgetpwent() from auth_flatfile.c so that
> > > it a) wouldn't require redundant trailing :::: [which confused the hell
> > > out of me the first time I used this] b) could allow the
> > > {scheme}password technique instead.
> > > 
> > > It's been a while since I paid much attention to the source so perhaps
> > > better ideas might be out there...
> > 
> > That's a fairly plausible idea. I think that the original
> > author was using a system where fgetpwent would work OK
> > without the trailing ::::. By all means patch it, though
> > if it could be back-compatible, that would be a plus....
> 
> My intention is simply to use the extant tokenising code in tpop3d. Add
> in the {scheme}password format `a la auth_mysql.c to make it a little
> more flexible.

OK.

> Now, to make it back compatible it would need to treat unix's salted
> crypt as the default rather than, as the current semantics are, MD5. I
> guess that's it, right?

Yeah. In fact the code for handling {scheme}hash is
embedded in auth-mysql.c; it would be feasible to decouple
it (the trendy word is `refactor', I think...), at which
point I guess it could be reused in auth-flatfile and a
putative auth-dbm.

> > Others have suggested DBM-based drivers, and I think I'd accept one.
> > One (obvious) comment is that you can't hold the DBM file open since
> > it has to be possible to change passwords while tpop3d is running.
> 
> Yep, I'd open in read-only too.

Yeah. Most DBM implementations allow many readers or one
writer.

> Right now, most likely I'll pull open the qpopper pop.auth database and
> generate the appropriate flat files which should work with the above
> addition allowing {plaintext}p@55w3rd

Sounds plausible.

> FYI, qpopper AFAIK uses DBM or GDBM and XORs the passwords with 0xFF.
> Puzzlingly, there seem to be, sometimes, two trailing NULs in the GDBMs
> produced by qpopper's popauth program. Maybe a bug...

Possibly. Never used it :)

-- 
``Damn! I'm running out of integers!'' (maths lecture)