[Mailman-Developers] [gpg] encrypted list management plug-in

[efkin]

On 11/11/2015 11:51 AM, Stephen J. Turnbull wrote:
> efkin writes:
> 
>  > from calafou hacklab & friends we wanted to reimplement schleuder in
>  > python.
> 
> URLs would be nice.

After some minimalist tackle to the problem we decided to start a small
research about the problem here[0]. And schleuder software is here[1].

[0] https://gitlab.com/calafou/lythyr/issues/1
[1] http://schleuder2.nadir.org/

>  > first and obvious question: is there already an ongoing effort to
>  > achieve gpg encryption that we could join?
> 
> Not really, although there's been discussion of it; see below.  The
> first big problem is use case; there are several and they demand
> somewhat different treatment.  I suppose your use case is defined by
> "schleuder", but I don't know what that is, and the first followup
> suggests that they aren't 100% sure themselves. :-)
> 
>  > after reading your Core docs, things are little bit more complicated:
>  > 1. the preprocess (and maybe postprocess?) of the messages could be done
>  > by what you call `chains` and `pipelines`
> 
> Just pipelines, most likely.  The basic idea is that chains determine
> whether messages are accepted for delivery at all, pipelines handle
> transformations and actual delivery to various targets.

Interesting.

>  > 2. the command system could be implemented extending the already
>  > existing Mailman command system (`echo` and `end`).
> 
> What command system?  Do you mean the REST interface, or the GSoC
> project to provide a nicer CLI?

something like what is described here:
http://mailman.readthedocs.org/en/release-3.0/src/mailman/commands/docs/end.html
it could be helpful, for example, to the mantainers of the encrypted
list to add one fingerprint/email to the mailing list object without
having to have shell access to the machine where it is installed.
maybe i just misunderstood what these commands are.
but the idea is that a mantainer could execute specific commands given a
special syntax in the firstline of an email.

>  > 3. it is just not clear how to prompt if encripton is desired in your
>  > ecosystem.
> 
> It is, at least by users.  There's been a GSoC project to add some
> signature and encryption capabilities (IIRC only signatures were
> implemented), but it's not been merged yet.
> 
> http://www.google-melange.com/gsoc/project/details/google/gsoc2013/maxking/5764017909923840
> 
> Abhilash, do you have anything to say? ;-)
> 
>  > * is there a plug-in way to tackle this problem?
> 
> What do you mean by "plug-in"?

well, basically something that could be packaged as mailman3-lythyr at
does not need to patch the core. i think Stefan suggested a modular
approach. and it seems quite reasonable.

>  > * do we really need to submit a merge request to the core instead of
>  > doing an optional debian package?
> 
> Given that you're intervening in the pipeline in a big way (have you
> considered what your "plugin" might imply for DKIM and DMARC, as well
> as various existing transformations that Mailman can apply?) and you
> say you need to "extend the command system", I think the latter would
> have to be considered a fork.  I doubt you'd get any support from the
> Debian maintainership or Mailman core if you do that.

we obviously want to avoid a fork. at the same time, the three of us,
that would work on this project, are quite unaware of mailman3 and
mailman in general architecture. but at the same time we are enthusiast
of researching it and happy to code for it.


>  > * are we totally on the wrong way? :)
> 
> Hard to tell.  I supervised the GSoC project mentioned above, but I
> have no idea what you're talking about with respect to "schleuder".
> That means there's a good chance nobody in core knows much, either.

well, hope the links i gave at the beginning are enough. if you need
some more info just let us know.

> So tell us about it, and then we'll tell you. :-)
>