From mark at msapiro.net  Fri Jun  2 21:59:53 2017
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 2 Jun 2017 18:59:53 -0700
Subject: [Mailman-Developers] Mailman 2.1.24 released
Message-ID: <edb090c6-caf4-85dd-da85-7caa2160cbe5@msapiro.net>

I am pleased to announce the release of Mailman 2.1.24.

Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended.

This release has a few new features, a few i18n updates and several bug
fixes. See the attached README.txt for details.

Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, please see our web site at one of:

http://www.list.org
http://www.gnu.org/software/mailman
http://mailman.sourceforge.net/
http://mirror.list.org/

Mailman 2.1.24 can be downloaded from

https://launchpad.net/mailman/2.1/
http://ftp.gnu.org/gnu/mailman/    (not yet updated as of this writing)
https://sourceforge.net/projects/mailman/

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
-------------- next part --------------
2.1.24 (02-Jun-2017)

  Security

    - A most likely unexploitable XSS attach that relies on the Mailman web
      server passing a crafted Host: header to the CGI environment has been
      fixed.  Apache for one is not vulnerable.  Thanks to Alqnas Eslam.

  New Features

    - There is a new RCPT_BASE64_HEADER_NAME setting.  If this is set to a
      non-empty string, that string is the name of a header that will be added
      to personalized and VERPed deliveries with value equal to the base64
      encoding of the recipient's email address.  This is intended to enable
      identification of the recipient otherwise redacted from "spam report"
      feedback loop messages.

    - cron/senddigests has a new -e/--exceptlist option to send pending
      digests for all but a named list.  (LP: #1619770)

    - The values for DEFAULT_DIGEST_FOOTER and DEFAULT_MSG_FOOTER have been
      changed to use a standard signature separator for DEFAULT_MSG_FOOTER
      and to remove the unneded line of underscores from DEFAULT_DIGEST_FOOTER.
      (LP: #266269)

  i18n

    - The Polish html templates have been recoded to use html entities
      instead of non-ascii characters.

    - The Basque (Euskara) translation has been updated by Gari Araolaza.

    - The German "details for personalize" page has been updated by
      Christian F Buser.

    - The Japanese translation has been updated by Yasuhito FUTATSUKI.

  Bug fixes and other patches

    - The list-owner at virtual.domain addresses are now added to virtual-mailman
      as they are exposed in 'list created' emails.  (LP: 1694384)

    - The 'list run by' addresses in web page footers are now just the
      list-owner address.  (LP: #1694384)

    - Changed member_verbosity_threshold from a >= test to a strictly > test
      to avoid the issue of moderating every post when the threshold = 1.
      (LP: #1693366)

    - Subject prefixing has been improved to always have a space between
      the prefix and the subject even with non-ascii in the prefix.  This
      will sometimes result in two spaces when the prefix is non-ascii but
      the subject is ascii, but this is the lesser evil.  (LP: #1525954)

    - Treat message and digest headers and footers as empty if they contain
      only whitespace.  (LP: #1673307)

    - Ensured that added message and digest headers and footers always have
      a terminating new-line.  (LP: #1670033)

    - Fixed an uncaught TypeError in the subscribe CGI.  (LP: #1667215)

    - Added recognition for a newly seen mailEnable bounce.

    - Fixed an uncaught NotAMemberError when a member is removed before a
      probe bounce for the member is returned.  (LP: #1664729)

    - Fixed a TypeError thrown in the roster CGI when called with a listname
      containing a % character.  (LP: #1661810)

    - Fixed a NameError issue in bin/add_members with
      DISABLE_COMMAND_LOCALE_CSET = yes.  (LP: #1647450)

    - The CleanseDKIM handler has been removed from OWNER_PIPELINE.  It isn't
      needed there and has adverse DMARC implications for messages to -owner
      of an anonymous list.  (LP: #1645901)

    - Fixed an issue with properly RFC 2047 encoding the display name in the
      From: header for messages with DMARC mitigations.  (LP: #1643210)

    - Fixed an issue causing UnicodeError in sending digests following a
      change of a list's preferred_language.  (LP: #1644356)

    - Enhanced the fix for race conditions in MailList().Load().  (LP: #266464)

    - Fixed a typo in Utils.py that could have resulted in a NameError in
      logging an unlikely occurrence.  (LP: #1637745)

    - Fixed a bug which created incorrect "view more members" links at the
      bottom of the admin Membership List pages.  (LP: #1637061)

    - The 2.1.23 fix for LP: #1604544 only fixed the letter links at the top
      of the Membership List.  The links at the bottom have now been fixed.

    - paths.py now adds dist-packages as well as site-packages to sys.path.
      (LP: #1621172)

    - INIT INFO has been added to the sample init.d script.  (LP: #1620121)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170602/a87a5506/attachment.sig>

From raj.abhilash1 at gmail.com  Wed Jun  7 18:18:43 2017
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Wed, 07 Jun 2017 22:18:43 +0000
Subject: [Mailman-Developers] Breaking mailmanclient into seperate modules
Message-ID: <1496873361.3v4tdrmjyj.maxking@angel>

Hi All,

Since we launched 3.1, I have been trying to add more docs in whatever free time
that I get. I have mostly been focusing on making Mailman 3 documentation more
easily acceible by both users and contributors. If you have any
thoughts/questions/concerns about the current state or suggestions for
improvement, please feel free to send them to this list or even me personally if
you don't want to send it to everyone for some reason.

One thing that I wanted to announce before I start is breaking up mailmanclient
from one giant module (src/mailmanclient/_client.py) to seperate class based
modules. The current setup works but is huge (1300+ LOC) and that is ok for now,
but I want to add docstrings to classes/methods and it would definitely make it
too big!

I would love to hear what others think about this.

-Abhilash

--
thanks,
Abhilash Raj

From johny at neuromancer.sk  Wed Jun  7 19:18:54 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Thu, 8 Jun 2017 01:18:54 +0200
Subject: [Mailman-Developers] Breaking mailmanclient into seperate
 modules
In-Reply-To: <1496873361.3v4tdrmjyj.maxking@angel>
References: <1496873361.3v4tdrmjyj.maxking@angel>
Message-ID: <82784c14-dff0-f86b-4947-5f80ac695ee0@neuromancer.sk>

On 06/08/2017 12:18 AM, Abhilash Raj wrote:
> One thing that I wanted to announce before I start is breaking up
> mailmanclient
> from one giant module (src/mailmanclient/_client.py) to seperate class
> based
> modules. The current setup works but is huge (1300+ LOC) and that is ok
> for now,
> but I want to add docstrings to classes/methods and it would definitely
> make it
> too big!
> 
> I would love to hear what others think about this.

Sure, I noticed that mailmanclient is strangely implemented in just one
large module while doing some MR's there. I think splitting it up is
definitely sensible. Considering the outstanding MR's, they should be
easy to rebase after the split as they don't "change" anything mostly
add stuff that will go to separate files after.

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/20170608/51df4b3f/attachment.sig>

From johny at neuromancer.sk  Wed Jun  7 18:45:42 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Thu, 8 Jun 2017 00:45:42 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v4
In-Reply-To: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
Message-ID: <2c797f51-4c9e-7a46-795f-f76230b1d67e@neuromancer.sk>

Hi all,

ad the first ~week of the GSoC period passes I am reporting the current
state of my work, comments appreciated! See below or at:

https://neuromancer.sk/article/5


=============================
 GSoC 2017 - About a week in
=============================

This week has been quite productive. I started laying the groundwork for
the encrypted lists plugin by making changes from
[core_changes](https://gitlab.com/J08nY/pgpmailman-proposal/blob/master/core_changes.md)
to different components of both Mailman Core, Mailman-Client and
Postorius. I will describe the MRs and ideas behind them here.


Mailman Core
============

Move pipelines to their own package and instantiate dynamically
---------------------------------------------------------------
[mailman!287](https://gitlab.com/mailman/mailman/merge_requests/287)

This MR makes Pipelines in Mailman Core work in the same dynamic way as
Handlers, Rules, Chains and other similar Mailman's components work.


Add plugin infrastructure
-------------------------
[mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288)

This MR is the biggest one and certainly the most important one for the
pgpmailman plugin and other potential Mailman plugins. It adds a notion
of a plugin to Mailman Core. To explain what I mean by a plugin, it's
best to look at its example configuration:

    [plugin.example]
    path: example_plugin
    class: example_plugin.plugin.ExamplePlugin
    enable: yes
    configuration: python:example_plugin.config.example

This configuration defines a plugin called example (section name). Which
resides in the example_plugin package with the
example_plugin.plugin.ExamplePlugin class implementing the IPlugin
interface, which I will describe in a moment. This plugin is enabled and
can use the path example_plugin.config.example.cfg to load it's
configuration.

Alright now what does this actually do / change / provide in Mailman Core?

 - The plugin's path package is searched for pluggable components if the
plugin is enabled and has a non-empty path value. A new function similar
to find_components is introduced and used, find_pluggable_components.
The components are searched for in subpackages named after what is being
searched, common to Mailman Core:

    - example_plugin.rules -> IRule
    - example_plugin.chains -> IChain
    - example_plugin.commands -> IEmailCommand
    - example_plugin.handlers -> IHandler
    - example_plugin.styles -> IStyle
    - example_plugin.pipelines -> IPipeline (after [mailman!287] lands)

 - The plugin's class is instantiated if the plugin is enabled and has a
non-empty class value (and implements the IPlugin interface). The
IPlugin interface has several methods:

    - pre_hook() -> Is called after instantiation but before Mailman's
db initialization, really just moved the existing pre_hook configurable
callable into a plugin infrastructure. Return value unused.

    - post_hook() -> Is called after pre_hook and after initialization
of Mailman's db and other dynamic components such as commands, rules,
handlers... Return value unused.

    - rest_object() -> Is called whenever a REST client calls the
/plugins/<plugin.name>/... route, to obtain an object which will respond
to REST queries for the plugin rooted at aforementioned route. This
method can return None to signify the plugin doesn't want to expose any
REST routes, in which case any calls by clients return 404. Otherwise
the object should use the routing system used by Mailman's REST api
(@child(), on_get and so on).

    - Mailman also sets the name attribute on the plugin object after
instantiation, before pre_hook to the plugin's name in configuration.

 - The plugin can use the path in it's configuration option to load it's
configuration if it needs a config file. The same path resoultion rules
apply as for the archivers configuration.


Add description attribute to styles
-----------------------------------
[mailman!289](https://gitlab.com/mailman/mailman/merge_requests/289)

Mailing list styles currently have an attribute for name, which for the
default styles is:

     legacy-announce
     legacy-default

Which is not particularly human-readable, well it is, but doesn't look
like something to be shown in a web ui such as Postorius. Mapping these
style names to their descriptions in Postorius is possible, however
since the styles are dynamically found and instantiated, it's not
something practically doable.

So this MR adds a description attribute to IStyle and adds the
appropriate descriptions to the default styles. Also exposes said
description to REST clients.


Mailman-Client
==============

Add bindings for specifying list style
--------------------------------------
[mailmanclient!28](https://gitlab.com/mailman/mailmanclient/merge_requests/28)

This MR adds missing access to the lists/styles REST api endpoint and
another argument style_name to the Mailman-Client's create_list call,
which is already recognized in Core and will create a new list with
selected style. This will then be used by Postorius.


Add plugin bindings
-------------------
[mailmanclient!34](https://gitlab.com/mailman/mailmanclient/merge_requests/34)

This MR depends on
[mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288) as
it really just exposes the new REST api added with plugins to
Mailman-Client. Since this new api gives plugins control over all the
requests to paths after their root, the api in Mailman-Client can not be
as high-level and abstracted as it is for lists and other core features.
It provides access to plugin's configuration and a Plugin.call(path,
data, method) similar to Connection.call.


Postorius
=========
Add list style selection to list creation view
----------------------------------------------
[postorius!214](https://gitlab.com/mailman/postorius/merge_requests/214)

This MR depends on
[mailmanclient!28](https://gitlab.com/mailman/mailmanclient/merge_requests/28)
and
[mailman!289](https://gitlab.com/mailman/mailman/merge_requests/289). It
adds another field to the list creation form, prompting the user to
select a list style, with the default being pre-selected and list style
descriptions being shown.


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/20170608/cab60898/attachment.sig>

From aurelien at bompard.org  Fri Jun  9 12:17:36 2017
From: aurelien at bompard.org (Aurelien Bompard)
Date: Fri, 9 Jun 2017 18:17:36 +0200
Subject: [Mailman-Developers] Breaking mailmanclient into seperate
 modules
In-Reply-To: <1496873361.3v4tdrmjyj.maxking@angel>
References: <1496873361.3v4tdrmjyj.maxking@angel>
Message-ID: <CAHmoxtXnX=+pOmGkzcqPCUOrZP0aiMVtk=oczfUQnLgG4eZAFQ@mail.gmail.com>

>
> One thing that I wanted to announce before I start is breaking up
> mailmanclient
> from one giant module (src/mailmanclient/_client.py) to seperate class
> based
> modules.


Yes please, I've been putting that off for a long time but I think it's
needed too.

A.

From barry at list.org  Fri Jun  9 23:19:52 2017
From: barry at list.org (Barry Warsaw)
Date: Fri, 9 Jun 2017 20:19:52 -0700
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v4
In-Reply-To: <2c797f51-4c9e-7a46-795f-f76230b1d67e@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
 <2c797f51-4c9e-7a46-795f-f76230b1d67e@neuromancer.sk>
Message-ID: <20170609201952.179bfc09@presto>

Hi Jan,

I haven't had a chance to look at the MRs yet, as it's my first week at a new
job.  But I have to say that your descriptions below look really great; I'm
impressed at how well your design fits in with Mailman overall, and how
clearly you've described them.  I'm not sure I could have come up with
anything better!

I have just a few questions, though we can hash out specifics on the MRs.

On Jun 08, 2017, at 12:45 AM, Jan Jancar wrote:

>Add plugin infrastructure
>-------------------------
>[mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288)
>
>This MR is the biggest one and certainly the most important one for the
>pgpmailman plugin and other potential Mailman plugins. It adds a notion
>of a plugin to Mailman Core. To explain what I mean by a plugin, it's
>best to look at its example configuration:
>
>    [plugin.example]
>    path: example_plugin
>    class: example_plugin.plugin.ExamplePlugin

I'm curious as to why you define both a `path` and a `class`, where the latter
has the former as the first component.  I'm not making a judgment (and haven't
looked at the branch yet), so I'm just wondering what led you to this decision.

>Mailing list styles currently have an attribute for name, which for the
>default styles is:
>
>     legacy-announce
>     legacy-default
>
>Which is not particularly human-readable, well it is, but doesn't look
>like something to be shown in a web ui such as Postorius. Mapping these
>style names to their descriptions in Postorius is possible, however
>since the styles are dynamically found and instantiated, it's not
>something practically doable.
>
>So this MR adds a description attribute to IStyle and adds the
>appropriate descriptions to the default styles. Also exposes said
>description to REST clients.

Have you thought about how these descriptions will be internationalized?
We'll clearly want to present style descriptions in the natural language of
the admins who are creating new lists with a particular style.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170609/59a057fa/attachment.sig>

From barry at list.org  Fri Jun  9 23:21:15 2017
From: barry at list.org (Barry Warsaw)
Date: Fri, 9 Jun 2017 20:21:15 -0700
Subject: [Mailman-Developers] Breaking mailmanclient into seperate
 modules
In-Reply-To: <1496873361.3v4tdrmjyj.maxking@angel>
References: <1496873361.3v4tdrmjyj.maxking@angel>
Message-ID: <20170609202115.29de3420@presto>

On Jun 07, 2017, at 10:18 PM, Abhilash Raj wrote:

>Since we launched 3.1, I have been trying to add more docs in whatever free
>time that I get.

Thanks Abhilash!

>One thing that I wanted to announce before I start is breaking up
>mailmanclient from one giant module (src/mailmanclient/_client.py) to
>seperate class based modules. The current setup works but is huge (1300+ LOC)
>and that is ok for now, but I want to add docstrings to classes/methods and
>it would definitely make it too big!

+1!

-Barry


From johny at neuromancer.sk  Sat Jun 10 10:20:26 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Sat, 10 Jun 2017 16:20:26 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v4
In-Reply-To: <20170609201952.179bfc09@presto>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
 <2c797f51-4c9e-7a46-795f-f76230b1d67e@neuromancer.sk>
 <20170609201952.179bfc09@presto>
Message-ID: <7c4cf6c2-81a2-e8ec-152b-ddb280fe04dc@neuromancer.sk>

Hi Barry!

On 06/10/2017 05:19 AM, Barry Warsaw wrote:
> Hi Jan,
> 
> I haven't had a chance to look at the MRs yet, as it's my first week at a new
> job.  But I have to say that your descriptions below look really great; I'm
> impressed at how well your design fits in with Mailman overall, and how
> clearly you've described them.  I'm not sure I could have come up with
> anything better!

That's great to hear!  Thank you and best of luck at your new job.

> 
> I have just a few questions, though we can hash out specifics on the MRs.
> 
> On Jun 08, 2017, at 12:45 AM, Jan Jancar wrote:
> 
>> Add plugin infrastructure
>> -------------------------
>> [mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288)
>>
>> This MR is the biggest one and certainly the most important one for the
>> pgpmailman plugin and other potential Mailman plugins. It adds a notion
>> of a plugin to Mailman Core. To explain what I mean by a plugin, it's
>> best to look at its example configuration:
>>
>>    [plugin.example]
>>    path: example_plugin
>>    class: example_plugin.plugin.ExamplePlugin
> 
> I'm curious as to why you define both a `path` and a `class`, where the latter
> has the former as the first component.  I'm not making a judgment (and haven't
> looked at the branch yet), so I'm just wondering what led you to this decision.
> 

I wanted the possibility of configuration, where for example the plugin
package might have more `IPlugin` classes with different behavior and so
the site admin might choose the plugin class he wants to use (a kind of
plugin super-package).  Or really just to not force the plugin creator
to put the plugin class in some specific path with relation to the
general plugin path which is used for loading components as the plugin
class is a specific kind of component (only one per plugin).

It might be fine to just drop the `class` part, load it in a similar way
as other components (so it will be in the `.plugin` subpackage of the
plugin package) and just enforce that one plugin entry in config can
provide only one `IPlugin` implementation.

>> Mailing list styles currently have an attribute for name, which for the
>> default styles is:
>>
>>     legacy-announce
>>     legacy-default
>>
>> Which is not particularly human-readable, well it is, but doesn't look
>> like something to be shown in a web ui such as Postorius. Mapping these
>> style names to their descriptions in Postorius is possible, however
>> since the styles are dynamically found and instantiated, it's not
>> something practically doable.
>>
>> So this MR adds a description attribute to IStyle and adds the
>> appropriate descriptions to the default styles. Also exposes said
>> description to REST clients.
> 
> Have you thought about how these descriptions will be internationalized?
> We'll clearly want to present style descriptions in the natural language of
> the admins who are creating new lists with a particular style.
> 

Hmm haven't thought about it yet, as I thought it was quite similar to
attributes of other Mailman's components, however this is indeed
different as it's not shown only to site admins but list admins /
through Postorius.  Will see what's possible there.

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/20170610/600d2212/attachment.sig>

From johny at neuromancer.sk  Mon Jun 12 15:35:47 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Mon, 12 Jun 2017 21:35:47 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v5
In-Reply-To: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
Message-ID: <bec87ab9-7e49-af12-0dcc-c69957bbdd5e@neuromancer.sk>

Hi all.

Sending an update here along with a new blog post.
https://neuromancer.sk/article/6


==============================
 GSoC 2017 - About the plugin
==============================

As last time I described outstanding PRs to Mailman Core and other
Mailman's components, this time I am going to describe the plugin I am
building on top of those components to enable PGP encrypted mailing lists.

In fact there are two plugins to present, with the first one being a
general and quick plugin example that showcases how the new plugin API
might be used and also provides some nice services for the PGP plugin.


mailman-rest-events
===================
[repo @ gitlab](https://gitlab.com/J08nY/mailman-rest-events)

This plugin subscribes itself to receive events in Mailman Core and
sends them to urls configured. It is a variation of what
[mailman!264](https://gitlab.com/mailman/mailman/merge_requests/264) is
intending to do, based on the plugin API implemented in my MRs. It
currently offers only basic functionality, a URL is specified in config
per `endpoint` along with an API key (very similar to
mailman-hyperkitty) and a regex of event class names that will be sent.
The data sent currently is only the event class name in a JSON object.
Config can have many `endpoints` specified with the form shown below.

[endpoints.django_mm3]
url: http://localhost/django/api
api_key: Something_secret_here
events: .*

Results in a call such as this one:

POST /django/api?key=Something_secret_here HTTP/1.1
...
Content-Type: application/json

{"event": "DomainCreatedEvent"}


The plugin is currently very bare bones and proper serialization of
events is underway. I am thinking of recursively serializing the
non-private event attributes until an easily serializable object is
reached, such as an `Address` or a `MailingList` or anything that has a
unique string associated with it and can be queried using the REST API
and such a string. So for example:


{
  "name": "DomainCreatedEvent",
  "event": {
    "domain": "example.com"
  }
}

or

{
  "name": "AddressVerificationEvent",
  "event": {
    "address": "anne at example.org"
  }
}


This plugin will be used by the mailman-pgp plugin to send events to
django-mailman3 which will distribute them to Postorius, HyperKitty and
the django app created to enable PGP encrypted mailing lists.


mailman-pgp
===========
[repo @ gitlab](https://gitlab.com/J08nY/mailman-pgp)

First of all, I think I came up with a name that better fits with
mailman-hyperkitty being an archiver "plugin" and in general with how
plugins for projects are named in python (flask_ext_... and so on).

As the general functionality and layout of the plugin was already
described I will mostly just summarise issues I am currently working on
tackling.


low level PGP work
------------------
I originally proposed using python-pgp
(https://github.com/mitchellrj/python-pgp
https://pypi.python.org/pypi/py-pgp/0.0.1) to use to parse and create
OpenPGP packets, as other libraries mostly offer only a high-level API
or are not so feature rich. However this library seems quite
un-maintained, so either a working fork should be established or a
different library used. I am currently looking at both options. Will
contact the original author as well as the current pypi package owner
and see what's possible.


public key on subscription
--------------------------
Since a PGP enabled mailing list needs to know the public key of a
subscribed address at the point when moderator approval is required,
some mechanism to do so is necessary. This needs to happen before
moderator approval, as the moderator / list owner should be able to see
/ download the provided key to verify it (or at least its fingerprint).
Currently I see two options, an extension of the proposed key command or
some changes to the current Subscription and Unsubscription workflows.

Extending the proposed key command would let the user use said command
to send and confirm his public key, before a subscription to an
encrypted list. This is similar to how schleuder does it. They
essentially run somewhat of a mailing key-server where the users might
submit keys via custom headers in message body.

However the current `SubscriptionWorkflow` and `UnsubscriptionWorkflow`
are really close to being able to require a custom additional step
during which the subscribers key is received and confirmed. Maybe making
`[Un]SubscriptionWorkflow` pluggable components, that can be set on a
per-list basis, similar to owner/posting chains or pipelines.

The second solution is definitely a more heavy-handed one, although
might be a better one in the long run. As it allows plugins to provide
[un]subscription steps which might be a nice use for plugins in Mailman
Core. I can imagine for example subscription verification where the
plugin verifies that the subscriber is a customer of some company by
showing the user a confirmation token in the customer system etc..


require confirmation for all commands
-------------------------------------
To address replay attacks where an attacker listens on a user performing
a command by sending it to the `list_id-confirm` address and then sends
the same message again in the future to replay the command, all commands
will need to require confirmation. This stops the attacker since he
cannot obtain the cleartext of the message containing the confirmation
token, or even if he could, he cannot forge the signature on the
confirmation message (leaving endpoint security out-of-scope). To reuse
the `confirm` command, Workflows and confirmation would have to be
refactored out from subscription management.


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/20170612/3c752ad9/attachment.sig>

From johny at neuromancer.sk  Tue Jun 20 18:53:38 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Wed, 21 Jun 2017 00:53:38 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v6
 + questions
In-Reply-To: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
Message-ID: <d1e0860a-2cbc-d3dd-fc93-c430b4d12320@neuromancer.sk>

Hi all.

This update goes with my latest blog post about finding a good PGP
python library:

https://neuromancer.sk/article/7
(!the blog posts content is not equal to this post!)

Along with that I also implemented list keypair generation in the
mailman_pgp plugin. It is configurable (key type, key size) in the
plugin config and currently produces keys such as this one:

pub   rsa4096/0x539FD576AA401697 2017-06-19 [SC]
      5B810BA0660C2EBCF46B3354539FD576AA401697
uid                   [ unknown] Zzz <zzz-request at example.com>
uid                   [ unknown] Zzz <zzz at example.com>
sub   rsa4096/0x0AC655A0580B8CE6 2017-06-19 [E]

This keypair generation is done via spawning another process on
encrypted list creation. Since the process might take quite some time,
it would create problems if, for example, the encrypted list was created
by the REST runner which would then go off to create the keypair for a
few seconds while requests keep timing out.

I also implemented PGP/MIME and inline PGP utilities. They can check
whether a message is signed/encrypted as per RFC1847+RFC3156 for the
former, and per some custom strict rules for the latter(inline PGP).
They can verify/decrypt both PGP/MIME and inline PGP messages. These use
the PGPy library I found and blogged about.

After reading through some more of the discussion on mailman-developers
around GSoC 2013 OpenPGP integration, I've chosen to refine some of the
handling of both signatures and encryption in the PGP plugin, to address
some of the questions/concerns. Here I specify a high level overview of
signature handling, i.e. what should happen, not how should it be
implemented.


Signature handling
==================

Per-list configuration
----------------------

   Option                   Default
   --------------------     -------
 - unsigned_msg_action      bounce
 - inline_pgp_action        None (pass-through)
 - expired_sig_action       bounce
 - revoked_sig_action       bounce
 - duplicate_sig_action     bounce
 - malformed_sig_action     bounce
 - strip_original_sig       False
 - sign_outgoing            False

Posting to
----------
# Assumes mailman_pgp already has a confirmed users public key.

1. User signs his message, either via PGP/MIME or inline PGP.

2. Sends to list posting address.

3. mailman_pgp

   - checks if the message is for a PGP enabled mailing list. If not,
passed it directly to the default incoming runner.
   Else go-on.

   - checks if the message is signed or not. If unsigned, the
`unsigned_msg_action` is taken.
   Else go-on.

   - checks if the message is inline PGP signed. If so, the
`inline_pgp_action` is taken.
   Else go-on.

   - checks if the signature verifies with the users public key. If not,
the `malformed_sig_action` is taken.
   Else go-on.

   - checks if the users public key that signed the message has been
revoked or expired. If so the `revoked_sig_action` and
`expired_sig_action` is taken, respectively.
   Else go-on.

   - looks up the signature hash and timestamp in the collection of all
of them mailman_pgp ever saw. If it finds it, then the
`duplicate_sig_action` is taken.
   Else go-on.
   ^^ I am not sure about this step ^^. It was proposed in the 2013
discussion, to avoid replay attacks on posting (replay attacks on
commands are solved by requiring confirmation).

4. If it reached this step, with no actions being taken then the message
is considered a good posting as far as mailman_pgp is concerned.

   - If it is inline signed, the signature ASCII-armor is moved from the
message body and stored in `msgdata` and the cleartext of the message
remains in the message body.

   - If it is MIME signed, the signature bodypart is "unwrapped" from
the multipart/signed (as per RFC1847) with the signature ASCII-armor
stored in `msgdata` and only the inner part of the first payload as the
message body.

5. Continue message processing as any other list.

Outgoing posts
--------------

1. If the list is configured to `strip_original_sig`, go-on. If not
attach the signature from `msgdata` back to create a PGP/MIME signed
message. (don't output inline PGP...)

2. If the list is configured to `sign_outgoing` add another signature
packet from of the mailing lists private key signing the message body,
to the signature ASCII-armor.

3. Send out.


Questions / Discussion points
=========

 - Should mailman_pgp keep all the signature hashes and timestamps it
received to stop replay attacks on posting? A replay attack on posting
without it is trivial.

 - Should the users keys be per user or per address? From a PGP
perspective per user makes more sense, as PGP keys have more user-ids,
so a user just sets up his key once, and it covers addresses in all his
user-ids. However per-address is more flexible, and the keypair must be
confirmed per-address anyways. A subscription is also per-address(a user
through a preferred address).

 - Aren't the options specified for signature handling too much? revoked
and expired sig_action could be merged, maybe even malformed.

 - Should we "unwrap" the signed message, as I propose, before passing
it to the rest of Mailman core?


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/20170621/d7910578/attachment.sig>

From barry at list.org  Thu Jun 22 18:29:28 2017
From: barry at list.org (Barry Warsaw)
Date: Thu, 22 Jun 2017 18:29:28 -0400
Subject: [Mailman-Developers] GitLab 9.3 feature
Message-ID: <20170622182928.62650750@subdivisions.wooz.org>

Gitlab 9.3 was just announced.  I wonder if this would help with some of our
problems coordinating between our various services, especially with the VCR
tape generation.

https://about.gitlab.com/2017/06/22/gitlab-9-3-released/?utm_medium=email&utm_source=marketo&utm_campaign=newsletter&utm_content=June+22+2017&mkt_tok=eyJpIjoiWlRneU5qUmlZamhoTXpFdyIsInQiOiI1U01mZkFYck1Ia3YxNkdhUWxMS0Z5K1pCSkd5bWxcL1BLUWh6YTN5d2JpWGdvcEI0M29pZmoyZ2hjUmxoNUFkcGdrQXEzWmU4K1IzaGJUU0FkNk4xQkc4MHVXb1o2NEw3cjBPaGJtMjRTZm43RU9XZGY5QkwzWUE0Q2hCa3dFdXUifQ%3D%3D#multi-project-pipeline-graphs

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170622/568a1c27/attachment.sig>

From johny at neuromancer.sk  Fri Jun 23 17:50:08 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Fri, 23 Jun 2017 23:50:08 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v7
In-Reply-To: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
Message-ID: <08ee064d-220e-57c7-81e6-54ddee87e70b@neuromancer.sk>

Hi all!

Another blog post is up. Copy follows for discussion.
https://neuromancer.sk/article/8


PGP handling progress
=====================

This week things moved along with the mailman-pgp plugin. As I finally
had a good PGP library to work with as well as some basic plugin API
patches outstanding to Mailman Core.

So with that I implemented large parts of the `mailman_pgp.pgp` package,
including tests, as well as a basic signature checking rule. Also, as
the package now contains tests, I added a gitlab CI config and started
running it.

[repo @ neuromancer.sk](https://neuromancer.sk/git/mailman-pgp.git)
[repo @ gitlab](https://gitlab.com/J08nY/mailman-pgp/)


Wrappers
--------

Created two classes, which wrap an `email.message.Message` instance (or
`mailman.email.message.Message`) and expose a common public PGP handling
API on said instance. One understands PGP/MIME (as per RFC1847 and
RFC3156) and the other somewhat understands inline PGP. They both give
methods to check presence of a PGP signed/encrypted message or PGP keys,
to verify signatures of a message, to decrypt it or collect the attached
keys. There are currently almost complete tests for handling signatures
and partial for encryption.

MIMEWrapper
-----------
This one was rather easy to implement, as RFC3156 and RFC1847 are both
very precise but also rather simple standards (well compared that to 90+
page RFC4880 [OpenPGP]).

InlineWrapper
-------------
As there is really no "Inline PGP standard" this wrapper improvises with
how it looks for signatures/messages/keys. In it's current form it only
accepts a non-multipart message and looks for ASCII-armored blobs in it.


Signature rule
--------------

The concrete way of integrating the PGP plugin into Mailman Core has
changed over time. The original version of my proposal planned on
working in the Mailman Core tree and as that changed to a plugin, new
requirements of integration popped up, us stuff couldn't just be changed
for this one plugin to work.

Because of the nature of encryption the PGP plugin needs to get it's
hands on the messages before the rest of Mailmans rules. This could be
done with a rule in a custom chain, however as I understand rules, they
are, well, rules, they shouldn't change the message they are processing
in any way. In my understanding of this architecture, if Mailman was
written in a language with a `const` identifier, the message would have
it in the chain links `process` method. It would work as a rule, just
wouldn't feel nice and fit in with the architecture.

That's why I first wanted to implement all handling of incoming messages
in a custom incoming runner. This runners class is then set as the
runner for the `in` queue and the default runner is moved to another
queue, perhaps `in_default`. The custom incoming runner does it's thing
before passing messages back to the default incoming runners queue.
However only encryption has this issue of needing to change the message,
as rules and the rest need it in cleartext. So I decided to split off
signature handling to a custom rule, and only handle encryption in the
incoming runner.

I would like to get rid of the not-so-nice redirection of the default
incoming runner altogether but I see no other way to decrypt the
incoming message to a PGP enabled list before other rules get it.

The signature rule processes messages using the wrappers described above
according to a per-list signature handling configuration:


  Option                 |  Default
  --------------------   |  -------
  unsigned_msg_action    |  bounce
  inline_pgp_action      |  None (pass-through)
  expired_sig_action     |  bounce
  revoked_sig_action     |  bounce
  malformed_sig_action   |  bounce
  duplicate_sig_action   |  bounce
  strip_original_sig     |  False
  sign_outgoing          |  False

I think the options are quite self-explanatory. They are checked in
order and taken if the message matches the option and the set action is
not `None`. So with the default configuration of the PGP enabled mailing
list, an unsigned message will be bounced, inline PGP is allowed,
signatures by expired keys are bounced (expired at time of checking),
signatures by revoked keys are bounced, signatures that don't verify are
bounced (maybe a better name for them than malformed?) and finally
signatures that the Mailman PGP plugin already processed are bounced as
well. This is to prevent replay attacks and is something I think people
would expect Mailman to do, although I am not sure if the plugin should
do it.

This signature rule is almost complete, with some edge-cases remaining
and the checking of duplicate signatures also remaining.

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/20170623/615fb407/attachment.sig>

From raj.abhilash1 at gmail.com  Mon Jun 26 11:14:36 2017
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Mon, 26 Jun 2017 15:14:36 +0000
Subject: [Mailman-Developers] Mailman 3 Container Images v0.1
Message-ID: <595124df.4e4d650a.858fc.178d@mx.google.com>

Hi Everyone,

I have been working on containerizing Mailman 3 so that it becomes
easier to test and try Mailman 3. There are two images in total:

* maxking/mailman-core : This consists of Mailman Core and includes the
  plugin to enable the Hyperkitty Archiver.
* maxking/mailman-web : This consists of a full Django installation and
  run the Mailman's Web UI components. It has Mailman Client, Postorius
  & Hyperkitty.

The images are built from the Dockerfiles hosted on Github[3] in case
you want to look at it. You can find most of the documentation about
these images at https://asynchronous.in/docker-mailman/. The version of
the internal components included in each image is available here[7].

The images are versioned and the process is documented[4], please have a
look before you use them. Also, the images are signed and I encourage
you to verify them before using. The process of how-to verify is also
documented.

Docker Compose is a tool written in Python makes is very easy to deploy
connected-images and take the pain out of writing long long commands for
spinning of containers. There is a sample `docker-compose.yml` file in
the Github repository mentioned above which is kind-of tested to be able
to spin off these images in vanilla condition (without any
customization/configuration).

You can report issues, comments or concerns in the Github repo[6].


[1]: https://hub.docker.com/r/maxking/mailman-core/
[2]: https://hub.docker.com/r/maxking/mailman-web/
[3]: https://github.com/maxking/docker-mailman
[4]: https://asynchronous.in/docker-mailman/#release
[5]: http://semver.org/
[6]: https://github.com/maxking/docker-mailman/issues
[7]: https://github.com/maxking/docker-mailman/wiki

--
thanks,
Abhilash Raj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170626/556eb34e/attachment.sig>

From johny at neuromancer.sk  Wed Jun 28 07:49:29 2017
From: johny at neuromancer.sk (Jan Jancar)
Date: Wed, 28 Jun 2017 13:49:29 +0200
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - first
 evaluation
In-Reply-To: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
Message-ID: <14838ede-7cdd-503a-f932-5a66dd8aea37@neuromancer.sk>

Hi all.

https://neuromancer.sk/article/9

The first evaluation period is here, I have already sent in my
evaluation so I thought I would recap the state of the project.

During the first two weeks or so, I mostly focused on features in
Mailman Core that would be necessary for making a plugin like this work,
my MRs introduce an easy to use/configure plugin infrastructure. Where
plugins can provide components and even custom REST routes in Mailman
Core. This with just installing the plugin into the same environment as
Mailman Core and some config additions. Also some minor additions of
selecting the list style on creation in Postorius and appropriate
changes in mailman-client.

During the last two weeks I focused on work on the mailman-pgp plugin
itself, along with its helper plugin mailman-rest-events. The REST
events plugin is finished, apart from some tests and bug-fixing and it
does its job of sending Mailman Core events to RESTful application
endpoints fine.

The mailman-pgp plugin currently has working list-key generation,
decryption in incoming runner, signature checking rule and general
inline and PGP/MIME message handling utilities. I also got its tests to
work with Mailman Core test layers so it can be actually integration
tested as it would work with Mailman Core. Along with that I setup
Gitlab CI pipelines with coverage testing and currently [tests
pass](https://gitlab.com/J08nY/mailman-pgp/pipelines/9384851)!

As I worked in PGP handling in messages I needed a good python [PGP
library](https://github.com/SecurityInnovation/PGPy), which I found, but
since some features mailman-pgp requires were not implemented/buggy I
made quite a lot of
[PRs](https://github.com/SecurityInnovation/PGPy/pulls) to this library
as well.

Key management is the next thing I would like to work on after finishing
tests of the current implementation. After that outgoing message
encryption and signing. When these things work I would then move on to
implement the appropriate things in the django-pgpmailman web app which
hooks into Postorius and HyperKitty.

Overall I am quite confident in where the project is now. Seeing it run
tests with Mailman Core running and pass (just some basic tests atm)
feels good.

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/20170628/941a2e27/attachment.sig>

From barry at list.org  Wed Jun 28 09:56:56 2017
From: barry at list.org (Barry Warsaw)
Date: Wed, 28 Jun 2017 09:56:56 -0400
Subject: [Mailman-Developers] [GSoC] Encrypted mailing lists - first
 evaluation
In-Reply-To: <14838ede-7cdd-503a-f932-5a66dd8aea37@neuromancer.sk>
References: <c9df9af7-a265-d261-adc2-a94cb4db3198@neuromancer.sk>
 <14838ede-7cdd-503a-f932-5a66dd8aea37@neuromancer.sk>
Message-ID: <20170628095656.7b565672@presto>

On Jun 28, 2017, at 01:49 PM, Jan Jancar wrote:

>Overall I am quite confident in where the project is now. Seeing it run
>tests with Mailman Core running and pass (just some basic tests atm)
>feels good.

Thanks for the update, and really great work Jan!  I'm slowly making my way
through the changes to improve plugins to the core, but I really like the
direction you've chosen.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170628/2b51640f/attachment.sig>

From simon.hanna at serve-me.info  Fri Jun 30 08:21:39 2017
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Fri, 30 Jun 2017 14:21:39 +0200
Subject: [Mailman-Developers] Next Postorius release
Message-ID: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>

Hi,

I know it might be a little early, but I'd like to talk about the plan
for Postorius (Mailman in general) releases moving forward.

Should there be more point releases? 3.1.X? Or just 3.X? Are releases
bound to Core releases (following core's release numbering?)? How often
do we do releases?

Every X merge requests and/or X months?

I'd like to know that just to organize issues/merge requests and so the
whole process can be planned a little more...

Would be also helpful to create this information in Gitlab milestones...


cheers,

Simon


From barry at list.org  Fri Jun 30 10:33:48 2017
From: barry at list.org (Barry Warsaw)
Date: Fri, 30 Jun 2017 10:33:48 -0400
Subject: [Mailman-Developers] Next Postorius release
In-Reply-To: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>
References: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>
Message-ID: <20170630103348.63c4a319@presto.wooz.org>

On Jun 30, 2017, at 02:21 PM, Simon Hanna wrote:

>I know it might be a little early, but I'd like to talk about the plan
>for Postorius (Mailman in general) releases moving forward.
>
>Should there be more point releases? 3.1.X? Or just 3.X? Are releases
>bound to Core releases (following core's release numbering?)? How often
>do we do releases?
>
>Every X merge requests and/or X months?
>
>I'd like to know that just to organize issues/merge requests and so the
>whole process can be planned a little more...
>
>Would be also helpful to create this information in Gitlab milestones...

Hi Simon, thanks for bringing this up.  It's not at all too early to discuss
this, and it's something I've struggled a bit with as well.

TBH, part of my problem with this is tooling.  I think both git and gitlab
aren't as amenable to long-term maintenance release administration as say bzr
and Launchpad.  Sure, we can create git branches for maintenance releases, but 
I don't think the cherry picking workflow is nearly as well documented or
consistently applied across projects as with bzr.  Worse, I really miss the
notion of "bug tasks" in Launchpad, where a single bug can target mutiple
maintenance releases, and each such target can be closed separately.  Watching
what happens in upstream Python for example; so much extra tooling had to be
created to manage that, although they do have a worse problem because there
are many more versions active at the same time.  (FWIW, github isn't any
better here.)

I did release Core 3.0.x maintenance release and intended to continue to do
so, but 3.1 eventually diverged to much and it was simply infeasible given my
available cycles.  The branch still exists, but we'll never release off of it
now so I've been thinking about tagging it and deleting the branch.

For Core 3.1, we do have a release-3.1 branch and I've started to label some
bugs as 'backport candidate' for things I think could or should be backported
from 3.2 (master).  Cherry picking them is Work though, so we'll see if it
happens.  There may be more pressure to do maintenance releases as usage
increases, and once we start seeing e.g. Debian packages and more update on
Abhilash's docker images.

From a policy standpoint, I'd suggest the following:

* "Major" releases (second digit, much like Python) should be coordinated.
  I'd like to align our release on the same Major.Minor version numbers.

* Maintenance releases can be left up to the individual components.  Do them
  if you can, and just rev the third digit as you see fit.  We don't need to
  coordinate them, though it's critical that we remain even more vigilant
  against breaking any APIs in point releases.  That's probably most incumbent
  on mailmanclient and Core.

* As to what to cherry pick, that's also up to the individual projects.  As
  mentioned, in Core I'm tending to label things as "backport candidate", but
  still closing them when they are landed on master.  I'm definitely open to
  suggestions here.  I think we should be consistent across projects so it's
  easier to track.

* Yes, we should do point release milestones both in the individual projects
  and as a suite.

It still of course means we have to find the resources to do the cherry picks
and releases. :(

Very much open to other thoughts and suggestions!
-Barry

From raj.abhilash1 at gmail.com  Fri Jun 30 15:24:06 2017
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Fri, 30 Jun 2017 19:24:06 +0000
Subject: [Mailman-Developers] Next Postorius release
In-Reply-To: <20170630103348.63c4a319@presto.wooz.org>
References: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>
 <20170630103348.63c4a319@presto.wooz.org>
Message-ID: <1498850520.jam0lge03w.maxking@angel>

Excerpts from Barry Warsaw's message of June 30, 2017 7:33 am:
> 
> It still of course means we have to find the resources to do the cherry picks
> and releases. :(

Have you looked at Mariatta's new cherry-picker tool for CPython
workflow? It seems to make the cherry-picking and backporting a bit easier.

[1]: https://github.com/python/core-workflow/tree/master/cherry_picker

--
thanks,
Abhilash Raj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170630/cdf877db/attachment.sig>

From raj.abhilash1 at gmail.com  Fri Jun 30 16:18:53 2017
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Fri, 30 Jun 2017 20:18:53 +0000
Subject: [Mailman-Developers] Next Postorius release
In-Reply-To: <20170630161505.0f1a0373@subdivisions.wooz.org>
References: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>
 <20170630103348.63c4a319@presto.wooz.org>
 <1498850520.jam0lge03w.maxking@angel>
 <20170630161505.0f1a0373@subdivisions.wooz.org>
Message-ID: <1498853834.vftdvhup2n.maxking@angel>

Excerpts from Barry Warsaw's message of June 30, 2017 1:15 pm:
> On Jun 30, 2017, at 07:24 PM, Abhilash Raj wrote:
> 
>>Have you looked at Mariatta's new cherry-picker tool for CPython
>>workflow? It seems to make the cherry-picking and backporting a bit easier.
>>
>>[1]: https://github.com/python/core-workflow/tree/master/cherry_picker
> 
> I haven't yet used it for CPython, but I've been watching its development and
> it looks like an awesome tool.  I don't know how specific it is to Github or
> CPython's workflow yet, but it's worth investigating.

With a quick look it seems to be not tied to Github except for the URLs
it automatically generates for creating a merge request on Github. The
rest of the actions are dependent on the local git repo.

> 
> -Barry
> 

--
thanks,
Abhilash Raj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170630/40bf9fa5/attachment.sig>

From barry at list.org  Fri Jun 30 16:15:05 2017
From: barry at list.org (Barry Warsaw)
Date: Fri, 30 Jun 2017 16:15:05 -0400
Subject: [Mailman-Developers] Next Postorius release
In-Reply-To: <1498850520.jam0lge03w.maxking@angel>
References: <4123dc79-1652-4c20-797e-d5d78742cba2@serve-me.info>
 <20170630103348.63c4a319@presto.wooz.org>
 <1498850520.jam0lge03w.maxking@angel>
Message-ID: <20170630161505.0f1a0373@subdivisions.wooz.org>

On Jun 30, 2017, at 07:24 PM, Abhilash Raj wrote:

>Have you looked at Mariatta's new cherry-picker tool for CPython
>workflow? It seems to make the cherry-picking and backporting a bit easier.
>
>[1]: https://github.com/python/core-workflow/tree/master/cherry_picker

I haven't yet used it for CPython, but I've been watching its development and
it looks like an awesome tool.  I don't know how specific it is to Github or
CPython's workflow yet, but it's worth investigating.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170630/cbfe5543/attachment.sig>