A few quick comments on the taint check thing:
1) The taint check was (partially) added because it's a giant pain to add later. Remove it is easy, adding it is hard. Maybe just turning it off is the right answer.
No, it still has some value, but like strict, it sometimes gets in the way more than it helps. I just thought that extending config() to include a validation hook (which just so happens to cleanse any taint) would be a way to kill two birds with one stone.
2) It's mostly (only?) useful to keep things coming from the network "in check".
3) Adding some "check/conform/validate the configuration" feature to the config interface might be useful if it's optional, but I don't think it should be done "because of taint".
I just observed that many modules were validating their input and cleansing the taint at the same time. I know that's my motivation when I wrote it. ;-)
4) If someone adds a config plugin that gets some of the configuration from "untrusted" sources, that plugin should check it for Evil Values I think. Maybe by plugging into the "check the value" option if that is added. :-)
I guess the question then becomes "Are the config files on disk, whether in the qmail tree or under ./config to be considered trusted or not?" If so, we could simply make _config_from_file() or even get_qmail_config() itself automatically cleanse taint, even without a validation test.
5) Options to the config thing should be a hashref; how the map/cdb option is implemented now is bad and ugly.
If I add a config extension as a hashref, should I rewrite the current usage of "map" at the same time? It only applies to:
rcpt_ok
check_relay
virus/kavscanner
sender_permitted_fromI see that exe_filter and greylisting have something like:
my @config = $self->qp->config('exe_filter', { rcpt => $rcpt });which looks to be the per-user config hooks. Adding a validation hook shouldn't disturb that at all, plus it makes that a supported interface...
John
