[Mailman-Developers] Pluggable workflows

[Jan Jancar]

Hi all!

As I note in one of my GSoC project updates, the PGP-enabled mailing
lists require two new features from Mailman Core, both related to
workflows. The first is to be able to inject steps into a subscription
workflow to request the users pubkey before moderation checks. The
second it to be able to require confirmation on all commands (to prevent
replay attacks), although this could be avoided by storing the hashes
from all the user sent signed commands. In this message I propose a way
of refactoring the workflows into pluggable components.

This post is also on my blog, for inline images I recommend going there:

https://neuromancer.sk/article/10


Current workflows
-----------------

Both of these requirements require changes to the way
[Un]SubscriptionWorkflows and workflows in general work. Currently the
subscription policy of a mailing list is determined by its
`subscription_policy` attribute of the `SubscriptionPolicy` enum.  That
policy is enforced in the `SubscriptionWorkflow` state machine, which
curently works with a queue of states, and looks like this:

[See attached subscription_workflow.png]

It is quite complex, and the `UnsubscriptionWorkflow` has much of the
same code except the verification and moderation parts.


Proposal
--------

What I propose is to make the [Un]SubscriptionWorkflows, more generally
workflows, pluggable components which would work on a stack state
machine and be composed of mixins like so:

[See attached subscription_workflow_split.png]

This way a mailing list will have the name of its `SubscriptionWorkflow`
component in the `subscription_policy` attribute.
Which would mean for example an `SubscriptionPolicy.open` would be
transformed into a class like so:


    @public
    @implementer(ISubscriptionWorkflow)
    class OpenSubscriptionPolicy(SubscriptionBase, VerificationMixin):
        """"""

        name = 'policy-open'
        description = 'An open subscription policy, only requires
verification.'
        initial_state = 'prepare'

        def _step_prepare(self):
            self.push('do_subscription')
            self.push('verification_checks')
            self.push('sanity_checks')


I believe this simplifies the policies and also allows chaining and
composing of workflow steps, which would enable plugins to add custom
subscription policies enforcing more steps/checks during the
[un]subscription process. For example an organization-only mailing list
could add a check that checks for the subscribing address in the
organization database, therefore removing the need for manual moderation
of subscriptions.

This should also allow for requiring confirmation of all commands, by
attaching a workflow instance to them. For the membership commands, this
would be the corresponding [Un]SubscriptionWorkflows, and for other
commands it would be currently disabled/empty workflow. Then a plugin
could set the confirm workflow on commands it needs to.


Comments?
---------

I am currently working on this as a MR [1], although I am not sure if
this is the right track to go on with workflows, so feedback/help is
appreciated. I think something to split the monolithic
[Un]SubscriptionWorkflows would be a nice thing in Mailman Core, as they
share a lot of the same code and are overly complex for what they are, a
linear series of checks with some skipping possible.


[1]: https://gitlab.com/mailman/mailman/merge_requests/299

Cheers,
-- 
Jan
______________________________________________________
   /\  # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
  /__\  # https://neuromancer.sk
 /\  /\  # Eastern Seaboard Phishing Authority
/__\/__\  #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subscription_workflow_split.png
Type: image/png
Size: 154466 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170703/f0bd1b08/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subscription_workflow.png
Type: image/png
Size: 88638 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170703/f0bd1b08/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170703/f0bd1b08/attachment-0001.sig>