[Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

[Barry Warsaw]

On Mar 15, 2017, at 09:47 PM, Rich Kulawiec wrote:

>What all of this means is that once a list passes N members, where
>we can debate about N, the probability that at least one of those
>members has already been compromised even before they've joined the
>list starts rapidly increasing.

That assumes an open membership policy.  Wouldn't much of this be mitigated
with a closed subscription policy?  I agree that the security of an encrypted
remailer such as we're discussing is only as secure as its recipients.  Yet
there still may be value in encrypting the communication channels into and out
of Mailman, even if that can be compromised at the end-points.

Does that make it worth it to add as a supported feature in the core?  It
depends.  What I would be very interested in -at least as a first step- are
ways to enable experimentation into such features by the addition of hooks and
APIs that allow third-party plugins that could support this feature.
Presumably such plugins would have utility for other use cases too.

>I can sadly report that the problem is getting worse and will continue
>to get worse, because (a) all of the various factors contributing to it
>are also getting worse and (b) there are no reasons for anyone to
>significantly invest in making it better.

(b) is not necessarily true.  There is lots of work going on to provide secure
base platforms on which to implement IoT devices.  Since that's mostly off
topic for this list, I'll avoid plugging technologies here, but if you know me
and my $dayjob, you can probably guess.  Feel free to email me off-list if you
want more information.

Cheers,
-Barry