[Mailman-Developers] [GSoC] Encrypted mailing lists

[Jan Jancar]

Hi all.

Currently still looking into what changes  will be necessary
in core in order to cleanly implement encrypted mailing lists
as a plugin, so this is my second status report. I will start
doing these pretty much weekly now, and definitely weekly/
more frequent when the coding period starts.

All of my reports (currently only this one) can be found on:
https://neuromancer.sk/
https://neuromancer.sk/recent.atom

(https://neuromancer.sk/article/2)

Also pasting it here for clarity and replies:

## Plugin API enhancements in Core

To cleanly implement encrypted mailing lists as a plugin to
Mailman Core I propose several general changes to the plugin
api, to allow for cleaner integration of plugins, more flexibility
and easier plugin deployment. First I present the current state
of pluggability in Mailman core and then present the proposed
changes.

### Current state

Relevant mailman-developers thread from GSoC 2015:
https://mail.python.org/pipermail/mailman-developers/2015-March/024477.html

Example plugin:
http://threebean.org/blog/plugins-for-mailman3/

 * A plugin creator has many ways of "injecting" his code to run
   at certain phases of Mailman's operation, since Mailman looks for
   its classes and components dynamically, it doesn't care whether 
   they are from a plugin or originally from core.

   - Implementing IHandler, IChain, IRule, IEmailCommand, 
     ICLISubCommand or IStyle and placing modules containing 
     the classes in the appropriate directories where Mailman
     finds them and instantiates them.

   - Implementing IRunner and adding the custom runner to
     mailman.cfg.

   - Implementing IArchiver and adding the custom archiver to
     mailman.cfg.

   - Implementing IMailTransportAgentLifecycle and setting the
     custom MTA in mailman.cfg.

   - Setting a custom callable in pre_hook or post_hook
     (only one callable per hook).

 * Core config variable ext_dir is unused.

 * There is not much documentation / examples of plugin creation,
   however core is very well documented so it's just a matter of
   figuring out what's pluggable or not.

### Proposed changes

 * Add configuration option similar to config.styles.paths to
   Handlers, Rules, Chains etc.. Which Mailman will use to look
   for components, so that plugins can just be accessible on the
   python path and not necessarily inside the Mailman package.
   Or use just one path per plugin and a standardized plugin structure:

   - plugin package
      - handlers
      - rules
      - chains
      - commands
      - pipelines
      - styles

 * Let plugins add Pipelines the same way they can add Handlers etc...

   - This means refactoring BasePipeline, OwnerPipeline,
     PostingPipeline, VirginPipeline from mailman.core.pipelines.py
     into a package mailman.pipelines

   - Use find_components

 * Let plugins subscribe to receive events.

 * Let List creator specify List Style when creating it through
   Postorius.

 * Allow multiple callables in pre_hook and post_hook run
   in order specified.

 * Drop ext_dir.


Cheers,
-- 
Jan
______________________________________________________
   /\  # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
  /__\  # https://neuromancer.sk
 /\  /\  # Eastern Seaboard Phishing Authority
/__\/__\  # 


-------------- 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/20170520/519676ff/attachment.sig>