Thoughts on processing for pre-approved messages
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've had several thoughts on what is now (in MM 3) done by rules/approved.py.
There is a moderator_password list attribute which can be used in a (X-)Approve(d): header or first body line pseudo-header to pre-approve a list post.
I've gone around a bit on this and I've concluded this is analogous to the list poster password I implemented for 2.1. Presumably we don't want to allow this password to be used to authenticate to the web ui. We may want to allow it for authentication for certain email commands. I'm not sure about that one.
My basic thought is we know who allegedly sent the post (maybe we have a few places to check - the poster might legitimately spoof the From:), so we can find a user who owns that address, see if the user has a moderator or admin role for this list, and validate the header password against that user's password. We *don't* want to do this because the user doesn't want to send her own personal password in a plain text email header. So we use this relatively easily changed and not very capable moderator_password instead.
So far, so good.
Now I see some issues with what rules/approved.py does. It checks for the header and validates the password. This is good. It also removes any header or body lines containing the pseudo-header from the message. Architecturally, this latter operation belongs in the pipeline, not in a chain rule. This seems to say we need both a rules module and a pipeline module (or maybe the existing pipeline/cleanse.py) to do this, and in the interest of DRY, we really need a mlist.check_approved(msg, clean=True|False) method to do the heavy lifting. Unfortunately, this adds complexity and potential for security lapses if the rule hits but the pipeline doesn't remove the authentication.
Thoughts?
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFPY3sxVVuXXpU7hpMRAodWAKCCcHOzCm3n7Ik9VUVapsUAHTvONwCghcoN qbND9+Opjm2D+Lb5PTqxIpg= =4wV2 -----END PGP SIGNATURE-----
On Sat, Mar 17, 2012 at 2:41 AM, Mark Sapiro <mark@msapiro.net> wrote:
I've gone around a bit on this and I've concluded this is analogous to the list poster password I implemented for 2.1. Presumably we don't want to allow this password to be used to authenticate to the web ui.
Right.
We may want to allow it for authentication for certain email commands. I'm not sure about that one.
This is a list policy thing. I wouldn't allow it, but then I don't plan to use X-Approve either.
Now I see some issues with what rules/approved.py does. It checks for the header and validates the password. This is good. It also removes any header or body lines containing the pseudo-header from the message. Architecturally, this latter operation belongs in the pipeline, not in a chain rule.
Strictly speaking, yes, but the whole idea of Approved: is unclean enough that I don't really have a problem with allowing a chain rule to remove the Approved: header. But maybe there should be a pipeline Handler that removes all Approved headers and pseudo-headers, regardless of whether it would actually work on that list.
we need a mlist.check_approved(msg, clean=True|False) method to do the heavy lifting.
I don't know about that. Having both one or more Handlers and a special seems like overkill, especially since really one checks the header and the other deletes, completely different functionality. Wouldn't it be better to have a class variable Mlist.approval_headers = ["Approve", "X-Approve"] and have
for h in mlist.approval_headers:
if msg[h] == mlist.moderator_password:
return True
return Falsefor the chain rule and
for h in mlist.approval_headers:
del msg[h]in a RemoveApprovalHeaders.py pipeline handler?
Unfortunately, this adds complexity and potential for security lapses if the rule hits but the pipeline doesn't remove the authentication.
Realistically, I don't think that's a problem. I think that more likely the problem will be that people will misspell the header, or use it in list that doesn't support approval-by-header, or grab an incorrect password out of an old message, or whatever.
participants (2)
-
Mark Sapiro -
Stephen J. Turnbull