On Sep 20, 2006, at 11:11 AM, John Peacock wrote:
Brian Szymanski wrote:
Hmmm... Pardon my ignorance, as I'm new to qpsmtp hacking (as the
following will probably lay bare!) - would having the information
in %auth_mechanisms in a package variable result in that
information staying "cached" when the plugins are changed? If so,
could that result in unexpected behavior for some folks as they
are changing auth plugins? (Yeah, I'm green). Besides that, it
sounds like a nicer way to do things, and it could conceivably
useful to have access to the info in auth_mechanisms hash in the
plugins themselves.
It isn't possible to change the plugins like that. If you are
running a long-running process (e.g. forkserver, prefork, or
Apache), the only way to change plugins is to restart the parent
service. Any attribute stored in the $self object
(Qpsmtpd::Transaction or ::Connection) is doubly slow (method
dispatch plus hash dereference) to access, plus there is the
duplicated information in each object that is, essentially, constant.
Ah, good deal.
Incidentally, on the subject of auth methods, I was looking at
adding CRAM-SHA1 support in Auth.pm, but it seemed to me that the
framework
CRAM-SHA1 is not, as far as I can tell, widely supported:
http://www.melnikov.ca/mel/devel/SASL_ServerRef.html
http://www.melnikov.ca/mel/devel/SASL_ClientRef.html
There's also the fact that the SHA-1 algorithm itself has been broken:
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
Any particular reason you want to support it?
Mostly for curiosity's sake. If I recall correctly there are serious
weaknesses with MD5 too.
I also can't help but thinking that a method with 7 arguments, at
least 2 of which are optional, might be better served with a hash.
Anyone have ideas on what this "should" look like?
Most (all?) of the internal subs in Qpsmtpd use positional
arguments (being much faster), whereas many (most?) of the plugins
seem to be migrating towards named arguments (being much friendlier
to the user). I don't see any compelling reason to switch.
This is also mostly a curiosity point, I'm actually wondering more
about whether ditching the clear and hashed passwords and just
passing one parameter, and letting the caller dispatch either by hook
or by $method makes sense to anyone but me. But then, it would
probably be a pain to be backwards compatible given that framework.
Thanks,
Brian
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---
Brian Szymanski
[EMAIL PROTECTED]
