Re: [Mailman-Developers] Mailman 2.1.21 Final Release

[Mark Sapiro]

On 02/28/2016 03:32 PM, Mark Sapiro wrote:
> 
> I am pleased to announce the release of Mailman 2.1.21.


It always happens. The only question is how. The thing is discovery of a
bug immediately after a release. This time the how was my PGP signature
being broken in the outgoing messages from 2 of the 4 lists I posted the
announcement to.  I have fixed the bug
. As far as I know it
only affects messages signed as PGP/MIME, not inline PGP, by Enigmail 1.9

In any case, I'm considering another release in a month or so which
opens another window for i18n updates. I strongly encourage anyone with
an interest in translations of Mailman to get the 2.1.21 release and
help with updating the translations. I did receive some updates for
2.1.21, but at this point the only translations that are 100% complete
are German, Japanese and Russian. If you can help with any of the
others, I encourage you to do so.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] About working on Issue #67

[Saurav Kumar]

I went through the slide "
https://speakerdeck.com/pyconslides/internationalization-and-localization-done-right-by-ruchi-varshney
" and then also through ZANATA webpage. I believe that i would be able to
work on this issue, to get start to contribute to Mailman
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Resuming mailman contribution

[Pranjal Yadav]

Hello all,

For those who don't know me,  I was a part of GSoC 2015 with Mailman, I
worked on the dynamic sublists aka dlist project. Terri and Steve mentored
me for this project and except for the timezone issue, I felt the
mentorship was one of the best experiences I have had in past few years,
Also Barry and Florian constantly helped me enhance my knowledge about mm3,
In totality it was a great experience. By the end of my project I started
with my first job and it was quite a hassle for few months, as soon as I
was about to settle I got a better opportunity and I switched. So long
story short I'm finally getting back after 6 months and its a wonderful
feeling.

I will take some time and resume the additional pieces that I missed in my
project, I'm more than happy to assist new GSoC applicants and share my
knowledge about Mailman core. I will try my best to answer your questions.

@Abhilash: Lets get in touch whenever you are free.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Regexp filtering

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Mar 01, 2016, at 04:37 AM, Stephen J. Turnbull wrote:

 > >Or we could continue to have the core representation be "leading '^'
 > >iff regexp", and once again have Postorius prepend "^.*" or whatever.
 > 
 > In which case, the core's model wouldn't have to change, right?

That's the point, yes!

 > I really want to avoid regexp-quoted strings for literals in the
 > model.  I'm fine if the core model doesn't change but Postorius
 > makes things nicer for the user.

OK on avoidance, you're the FLUFL after all!  If Terri or Florian
doesn't pipe up with total hate soon (== by the time I getta round
tuit), I'll file a feature request.

Steve
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Regexp filtering

[Barry Warsaw]

On Mar 01, 2016, at 04:37 AM, Stephen J. Turnbull wrote:

>Are regexps sufficiently slow that *always* using a regexp would hurt
>performance?[1]  The model I really had in mind was to always use
>regexps, and have a flag in the UI (Postorius) to regexp-quote when
>the user wants a literal.

I think it's less about performance and more about being explicit.  My own
sense is that literals are more common than regexps, and that in general
regexps are more difficult to understand, but I don't have a lot of data
points to back that up.

>Or we could continue to have the core representation be "leading '^'
>iff regexp", and once again have Postorius prepend "^.*" or whatever.

In which case, the core's model wouldn't have to change, right?

I really want to avoid regexp-quoted strings for literals in the model.  I'm
fine if the core model doesn't change but Postorius makes things nicer for the
user.

Cheers,
-Barry


pgpGVtohYY40u.pgp
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC Project: pgp plugin

[Stephen J. Turnbull]

Jonas writes:

 > On 28.02.2016 10:30, Stephen J. Turnbull wrote:

 > > End-to-end encryption or signature or both seems to be the right
 > > thing.
 > 
 > The concept of a mailserver doesn't allow real end-to-end encryption if
 > each recipient uses a different keypair.

It's true that keeping things secret from the server would be hard,
but at least in theory it would be possible to avoid decryption in
normal operation by having the originator use a "session key" and a
symmetric algorithm to do the actual encryption, and then using the
user's PGP key to encrypt the session key.  Then all you need to do is
decrypt the session key and reencrypt it with the user's (or users')
key(s).

If possible (I mean I suspect it requires privacy software that
doesn't currently exist) this would be nice because you don't have to
worry about having copies of decrypted text in memory, in swap, and in
temporary files.[1]  Of course this would mean that such an MLM could
not decorate the mail with header or footer, but you probably should
not do that anyway because of limitations of MUAs and users in
displaying/interpreting indications of what portions of a message are
secure.

 > Considering that all subscribers recieve the mail and usually
 > listserver admins are subscribers theirselves,

In security, you either need to take care of the unusual case, or
document that the case is not covered.  Wouldn't you rather have a
short list of "you can't use my software in these cases: ..."?

 > I think than an implementation where the listserver recieves a copy
 > as well definitly has some uses.

Copy of the encrypted message, maybe, although I would argue that
archiving should default to off for an encrypted list.  But decrypted,
I disagree strongly, and would do my best to block integration of such
a feature (it's Barry's call in the end, not mine).  If you really
want the server to have a decrypted copy, that is easily enough
accomplished by subscribing a decryption program to the list.  Our
goal should be to do our best to reduce the additional attack surface
presented by the MLM by default, and leave the users to their own
devices in reducing security and increasing risk.

 > Users would have to be aware that the privacy of communication
 > relies on the protection of the listserver and listserver admins
 > would have to be aware that they need to protect the lists keypair.

If there's anything we know about users, it's that they only learn
about security when they experience harm from lack of it, and even
then few actually do anything effective about it.[2]  Admins have
enough to worry about without drawing an arrow labeled "attack here"
on their system (running an encrypted list already paints a bullseye
on it).  Whenever possible, we want random clueless behavior to *not*
result in a security hole.  So yes, the private keys must be
protected.  But as much as possible we should try to ensure that if
the list server is compromised, the communications are not.

 >> [Automated key generation is out] of scope for one summer IMHO.
 >> It's not obvious what the security implications are.  Better to do
 >> key generation off-line.

 > What security implications are you refering to? Some servers have
 > true hardware rngs. If there isn't enough entropy, no keys should
 > generate with /dev/random as entropy source.  Having the proper
 > crypto libraries and random number sources is in the responsibility
 > of the user.

I'm not talking about the availability of these basic facilities.  If
the system doesn't have them, none of the necessary crypto facilities
will be available from Python anyway.  I'm talking about the
introduction of unnecessary complexity.  I don't know offhand how to
attack it.  I'm saying that before we introduce additional complexity
we need to be pretty sure that it's hard to attack.

If you want to do this, you need to learn the security mindset[3].
Otherwise, you're very likely going to leave behind bugs that someday
will bite somebody who is earnestly trying to do the right thing.

Back in the day, I set the config on Smail 3.1.0.99 to block outside-
to-outside relays, as recommended by the documentation.  I was shocked
to be informed a few weeks later that my box was being used as an open
relay.  Guess what?  They documented that feature, but the
implementation was a stub until 3.1.0.101.

 > With this concept, there will be a private key on the listserver and
 > this should be clear to the users. It has security implications but I
 > think they are admissible.

Of course there has to be a private key usable by the list server
because the whole purpose of the exercise is to avoid distribution of
all keys to all subscribers.  But stealing the keys is only one of the
many ways to get past a lock.  We need to protect the hinges on the
other side of the door, too.  The most effective way to do that is to
ensure they're not exposed in the first place.

 > > What does "trusted" mean?

 > Trusted means that the k

[Mailman-Developers] Introduction

[Jasvir Singh]

Hello everyone.
I am Jasvir Singh Grewal, a graduate student from CSU Long Beach. I am
feeling very excited to introduce myself on this mailing list. I have
been working on open source technologies since 3 years. Last 2 years I
have spent primarily working on Django and Python and it'll be a
pleasure for me if I can use my skills for Mailman.

Thank You
-- 
Jasvir Singh Grewal
https://github.com/jasvir99
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Regexp filtering

[Stephen J. Turnbull]

Barry Warsaw writes:

 > IBan would need to have a flag which indicate whether the `email`
 > is a literal address or a pattern.  I don't think it's worth having
 > two separate interfaces/models, but we might want to rename `email`
 > to something more generic (`pattern` would be fine, with the
 > understanding that is_regexp=False means the pattern is a literal).

Are regexps sufficiently slow that *always* using a regexp would hurt
performance?[1]  The model I really had in mind was to always use
regexps, and have a flag in the UI (Postorius) to regexp-quote when
the user wants a literal.

Or we could continue to have the core representation be "leading '^'
iff regexp", and once again have Postorius prepend "^.*" or whatever.


Footnotes: 
[1]  XEmacs actually checks whether a regexp contains any regexp
operators and automatically switches to a very fast literal search if
not.


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman 3 custom footer

[Barry Warsaw]

On Feb 29, 2016, at 10:54 AM, treal tv wrote:

>We are using Mailman 3 in production in a corporate environment. I'm willing
>to deal with the re-structuring of Mailman when 3.1 comes around :)

Nice!

Cheers,
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Regexp filtering

[Barry Warsaw]

On Feb 27, 2016, at 02:02 PM, Stephen J. Turnbull wrote:

>I hope we haven't propagated this rather user-unfriendly interface
>(the convention of accepting both regexps and literals, distinguishing
>by "^" in column 0) to Mailman 3.

Sadly, it's true.

Mostly this is historical since we've essentially just ported the data and
code from Mailman 2.  It was implemented this way because of the limitations
for data modeling, and the unsophisticated web ui in MM2.

We could do better in MM3, both because we can model the data better, we can
expose the distinction in REST, and Postorius could expose the difference in a
much better web ui.

Here's a rough sketch of what you'd have to do in the core to make this
change.  As always merge requests are welcome!

IBan would need to have a flag which indicate whether the `email` is a literal
address or a pattern.  I don't think it's worth having two separate
interfaces/models, but we might want to rename `email` to something more
generic (`pattern` would be fine, with the understanding that is_regexp=False
means the pattern is a literal).  You'll need to change a bunch of checks and
what-not in the ban management code.

This also shows up in AcceptableAliases, so a similar change would have to be
made to IAcceptableAlias, the various model implementation bits of that
interface, and the implicit_dest.py rule.

The REST API for these would probably need some additional work, but that
can't easily be done.  The trickiest part would be if IBan.email is renamed,
in which case you'd probably want to continue to accept the old data format
for the 3.0 API (and translate it into the new model layer), but only accept
the new data format in the 3.1 API.  There are examples of how to do
API-version differentiation.

It's still used in the *_these_nonmember checks (moderation.py rule), but as
these are legacy facilities from Mailman 2, I'm not sure they need to change.
Eventually, we want to remove these settings anyway, since all the
functionality is implemented differently and better in MM3 already.

Another odd use of this is in the `withlist` subcommand.

(It's also used in the wsgiref/falcon plumbing layer, but since that's all
internal implementation details, nothing here needs to change.)

You'd need to handle database migrations and documentation updates too, along
with a robust test suite, but there's nothing intractable about any of this.

Cheers,
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] GSOC 16

[Manish Bisht]

Hello devs,

Google is announcing the list of selected organisation for GSOC 16 in few
hours. Hope you all will like to join.

Mentor are welcome as they are needed to guide the students and students
are also welcome who would like to contribute. Think about the project idea
and post it to mailing list for suggestions. Or choose the projects from
the list.

Hope we will got selected (fingers crossed) :)
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] ARC module implementation [was: GSOC 2016]

[Barry Warsaw]

On Feb 29, 2016, at 12:08 PM, Stephen J. Turnbull wrote:

>[Aside @Barry:  what's the current state of DMARC handling in Mailman
>3?  (I assume below that there isn't any yet.)  I guess porting some
>or all of the Mailman 2 facilities be a good GSoC project?]

Correct!

Cheers,
-Barry


pgpS2KeCY9JFo.pgp
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman 3 custom footer

[treal tv]

Hey Barry! I'm a few days late to respond to this, but I just wanted to 
let you know I found this immensely useful, and my footer looks just 
like how I want it to be :)


We are using Mailman 3 in production in a corporate environment. I'm 
willing to deal with the re-structuring of Mailman when 3.1 comes around :)


Thanks again Barry.

On 02/26/2016 07:24 PM, Barry Warsaw wrote:

On Feb 25, 2016, at 02:36 PM, treal tv wrote:


I'm looking to modify the contents of this footer so it says something
slightly different. However, I can't find anywhere with Mailman 3 to change
anything about the footer.

I'll describe what you have today, but it's likely the exact details will
change at some point (maybe for 3.1 if my ideas pan out).  Still, how it works
today still contains the basic scheme for how I want it to work in the future.

The thing to remember is that while Core needs to send out emails with various
templates, it can't make any assumptions about what is on the web front-end,
so text like footers can't contain URLs and such by default.  Yes, this is a
bit of a mess right now because you'll still see substitutions like
$listinfo_url in some templates, even though these can't be correctly filled
in.

So there are two parts to this answer.  The first is finding the template to
use for the footer[*], and then filling in all the placeholders.

You've found the footer-generic.txt template, but how is this used?  Every
mailing list currently has an attribute called `footer_uri`, and this is set
in the list style.  I've previously described how style works so I won't go
down that detour here.  Suffice to say that the default style sets footer_uri
to `mailman:///$listname/$language/footer-generic.txt`.

Notice two things about this uri.

  * It has a `mailman:` scheme.
  * It has some $-placeholders.

What happens is that in the decorate handler, when the footer is put on the
outgoing message, we first substitute some useful information into the uri's
placeholders.  The values should be obvious: $listname gets the fqdn_listname
value and $language gets the preferred_language.code.  So for mailing list
al...@example.com using Italian as its preferred language, the footer_uri
gets transformed into mailman:///al...@example.com/it/footer-generic.txt.

Now we start to look that up.  Of course, if the scheme were http: or https:,
we'd just issue a request to that url and use whatever we find.  The intent is
that in Postorius or some other CMS or web resource repository, you'd be able
to define a custom template appropriate for your site.  You'd set the list's
footer_uri to something like https://my.cms.example.com/footer.txt and since
there are no placeholders, Mailman just grabs the text at that url and viola!
you've got your footer.  Supporting the placeholders allows your CMS to
provide different footers for different lists, and of course you'll want to
provide different footers for different human languages.

But okay, now we have mailman:///al...@example.com/it/footer-generic.txt and
we have to look that up.  What are the rules for mailman: urls?

mailman: urls are shorthand for internal resources, homed in the source code
directory on the file system.  The search order is well documented, but not
easily discovered so here's the documentation:

https://gitlab.com/mailman/mailman/blob/master/src/mailman/utilities/i18n.py#L53

You can see how there's a search hierarchy, such that if you only want a
single template for all your lists on the site, you can define it once on the
file system, and Mailman will just find that one.  Similarly, you could have a
template that applies to all lists within the same domain, or have list
specific templates.  So, bottom line is, drop a file in the template_dir
defined in your mailman.cfg and set your list's footer_uri to a mailman: url
that points here, and Bob's your uncle.

Now the second step alluded to earlier.  Once you've located the template, the
template *itself* can have substitution placeholders, and for message headers
and footers (i.e. message decorations) they get filled in here:

https://gitlab.com/mailman/mailman/blob/master/src/mailman/handlers/decorate.py#L228

So you can see how your template can contain information about the mailing
list's name, hostname, description, etc.  `extradict` comes into play (or at
least *should* ) when messages are personalized, such that some
information specific to the user could be added, e.g. their unsubscribe link.
This may not be fully plumbed out right now though.

Briefly then, how will this be different in the future?  I'm still working out
the design, but roughly, there will be a new ITemplateManager that holds
mappings between template names, a context (e.g. mailing list, domain, or
site), URIs, and "resource dictionaries".  This ITemplateManager would be a
top-level REST resource so Postorius and other REST clients could directly
manipulate these mappings.

Then you'd be able to say, through REST, "set the footer temp

Re: [Mailman-Developers] Gitlab integration, GSOC'16

[Terri Oda]

On 2016-02-28 1:34 PM, aahan bhatt wrote:

Please explain about the gitlab integration in layman terms. I would like
to contribute to the project.


Gitlab integration can mean a lot of things, and we've left this 
particular project pretty open to see what people will suggest.


The tweet linked talks about moving a discussion from a mailing list to 
a bug tracker.  So imagine that you have a bunch of people discussing an 
issue on a mailing list and after a few posts someone says "hm, that 
configuration didn't work the way I expected, this sounds like a bug, 
maybe we should file it" -- we want a way to dump the whole discussion 
into a bug so when someone goes to fix it they have all the information. 
 You'd need to think a bit about privacy (were the mailing list posts 
public?  what about the bug tracker?) and relevance of information (what 
if I only want some of the posts?  what if I want to link the discussion 
but only provide a summary?) to go from the idea of "make it easier to 
file bugs using information from a mailing list discussion" to an actual 
workable interface for doing that, but that's the core of it.



If you want to understand the whole gitlab integration idea better 
beyond that one use case, try brainstorming a little bit about how the 
pieces could work together.  How could a mailing list integrate better 
with a bug tracker?  How could it integrate better with merge requests? 
 What information would people want to pass from one system to the 
other and why?


For an example you might want to take a look at idea #27 on this page: 
http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/





___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Fwd: [Python-Dev] [ANNOUNCE] fuzzpy

[Terri Oda]

I know I was talking to someone a while ago about maybe doing some fuzz 
testing on Mailman.  If anyone's interested, this might be a tool worth 
trying out:



 Forwarded Message 
Subject:[Python-Dev] [ANNOUNCE] fuzzpy
Date:   Sun, 28 Feb 2016 21:44:39 -0600
From:   Brian Cain 
To: python-...@python.org



##

    *---*
    *    fuzzpy: CPython fuzz tester is now available   *
    *                                         Â
        *
    *                   Version 0.8               Â
    *
    *        https://bitbucket.org/ebadf/fuzzpy/        *
    *---*

I am pleased to announce the creation of a coverage-guided fuzz tester
for CPython.  It's a pretty small wrapper around LLVM's libFuzzer that
enables some powerful testing logic.  AFL (American Fuzzy Lop) is
another popular fuzzer lately -- libFuzzer is very similar in concept to
AFL.  From what I've read on list archives, Victor Stinner had
previously done some good fuzz testing on CPython using fusil.  This
project should expand on that concept.

I'd love to get feedback, suggestions, patches and anything else the
list can offer.


Q: What is fuzzpy for?
A: It's primarily for testing CPython itself, but could also be used for
individual python projects too.  Pure-python projects will be the
simplest to integrate at this point.  Also, interesting test cases
output by fuzzpy may end up being useful in testing others such as pypy,
pyston, etc.

Q: What is a fuzz tester?
A: It modifies inputs to a test case in order to find unique/rare failures.

Q: What does "coverage-guided" mean?
A: It means that libFuzzer is able to witness the specific code executed
as a result of a given test case.  It feeds this information back into
an engine to modify the test cases to optimize for coverage.

Q: How can I help?
A1: donate cycles: build the project and crank away on one of the
existing tests.  Relative to other common fuzzing, it's awfully slow,
so consider throwing as many cycles as you can afford to.
A2: contribute tests: write a ~10-line python script that exercises a
feature that you think could benefit from fuzz testing.
A3: if there's interest, I can accept cryptocoin donations to purchase
cycles on a cloud server.


##


--
-Brian


___
Python-Dev mailing list
python-...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/terri%40toybox.ca

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC Project: pgp plugin

[Abhilash Raj]

On 02/29/2016 03:02 AM, Jonas wrote:
> Hi Abhilash Raj, Hi Steve
> 
> Thank you both for taking the time and considering to mentor me.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> If you don't know, I worked on this project some time back in GSoC 2013.
>> The  current state of that project is not very good and probably needs a
>> *lot* of rebasing to do.
> 
> I did not know that. What were the problems?

I did implement the signature verification for the
application/pgp-signed emails and was able to get everything working
too. There was some plumbing left that I never went back to finish.

> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> Here is a link[1] to discussions that have already been done before on this
> 
> I think that link is missing, I'm very interested in looking into this.

Sorry about that, here it is
http://www.mail-archive.com/mailman-developers%40python.org/msg13413.html.

> 
> First of all, if this wasn't clear, my plan was to make a re-encryption
> gateway. Messages are encrypted to the listservers keypair and
> re-encrypted there for each of the recipients.
> How did your implementation work, Abhilash Raj?

Kinda similar, just that I mostly focused on just implementing the key
management and verifying digital signatures and figuring out a message
structure that would let us retain signatures from both list and
original sender.

> 
> I had two modes of Operation in mind:
>  (a) One that doesn't encrypt all of the mail but gives users the option
> to send and recieve pgp encrypted mails. This might be useful for very
> small private lists where some communication is protected against
> eavesdropping in other ways, when a list is in the progress of
> introducing encrypted communication or for (other) testing purposes.
>  (b) A strict mode that keeps all the communication encrypted and won't
> ever send out mail without encrypting it.
> 
> The strict (b) mode should certainly be default, and
>>  8. Optionally forced encryption (such a list never sends mail to an
>> adress to which it can't encrypt with a pubkey that has a certain
>> level of trust and/or won't accept inbound mail in plaintext)
> is in fact essential for the application to make sense. By Optionally, I
> meant that it should be possible to not force encryption which would be
> the (a) mode of operation.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>>
>> I have a few small questions doubts about your features below...
>>
>>
>>> Some features could be:
>>>  1. Automatic pubkey collection from inbound mail
>>>
>>
>> What happens if I send a forged email with some user's email address as
>> FROM and use a fake key? Automatic public key collection isn't a very good
>> idea, you should be *very* careful about how you handle public keys.
> 
> The idea was to collect the public keys so an authority (list admin)
> could manually set their trust levels which would be necessary in strict
> (b) mode in order to use a key at all.
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>>>  2. Outbound mail encryption and signature validation
>>>
>>
>> I would suggest you keep encryption as a part of extended goals in case of
>> GSoC. You'd be surprised how many students are not able to finish their
>> proposal in time.
> 
> I will try to make a realistic evaluation of what's possible in my GSoC
> before i apply.
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>>  >  2. Outbound mail encryption and signature validation
>>  >  4. Inbound mail decryption and outbound mail signature
>>
>> I don't understand these pairs.  Why encrypt mail *to* the server if
>> it's only going to be decrypted on the way out?  Why encrypt outgoing
>> posts if they might have been read in the clear before being received?
> 
> On 28.02.2016 04:48, Abhilash Raj wrote:
>> Shouldn't both be working differently? Encrypted
>> emails distributed as encrypted email and signed email distributed as
>> signed.
> 
> I paired them this way because outbound encryption and inbound signature
> validation requires the application to manage the subscribers public
> keys and inbound encryption requires the application to manage the lists
> keypair so I would probably implement 1. and 2. as well as 3. and 4. at
> the same time. 1-4 are part of the core functionality.
> My list is badly structured.
> 
> 
> On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>> End-to-end encryption or signature or both seems to be the right
>> thing.
> 
> The concept of a mailserver doesn't allow real end-to-end encryption if
> each recipient uses a different keypair.
> A user would have to have the public keys of all the subscribers at the
> time of sending a mail to the list and encrypt the mail for each of
> them. This would require modification to the client software for this to
> behave like a mailinglist, especially if subscribers join or leave the list.
> 
> A method for real end-to-end mailinglists is described in
> Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 [1]
> b

Re: [Mailman-Developers] GSoC Project: pgp plugin

[Jonas]

Hi Abhilash Raj, Hi Steve

Thank you both for taking the time and considering to mentor me.

On 28.02.2016 04:48, Abhilash Raj wrote:
> If you don't know, I worked on this project some time back in GSoC 2013.
> The  current state of that project is not very good and probably needs a
> *lot* of rebasing to do.

I did not know that. What were the problems?

On 28.02.2016 04:48, Abhilash Raj wrote:
> Here is a link[1] to discussions that have already been done before on this

I think that link is missing, I'm very interested in looking into this.

First of all, if this wasn't clear, my plan was to make a re-encryption
gateway. Messages are encrypted to the listservers keypair and
re-encrypted there for each of the recipients.
How did your implementation work, Abhilash Raj?

I had two modes of Operation in mind:
 (a) One that doesn't encrypt all of the mail but gives users the option
to send and recieve pgp encrypted mails. This might be useful for very
small private lists where some communication is protected against
eavesdropping in other ways, when a list is in the progress of
introducing encrypted communication or for (other) testing purposes.
 (b) A strict mode that keeps all the communication encrypted and won't
ever send out mail without encrypting it.

The strict (b) mode should certainly be default, and
>  8. Optionally forced encryption (such a list never sends mail to an
> adress to which it can't encrypt with a pubkey that has a certain
> level of trust and/or won't accept inbound mail in plaintext)
is in fact essential for the application to make sense. By Optionally, I
meant that it should be possible to not force encryption which would be
the (a) mode of operation.

On 28.02.2016 04:48, Abhilash Raj wrote:
> 
> I have a few small questions doubts about your features below...
> 
> 
>> Some features could be:
>>  1. Automatic pubkey collection from inbound mail
>>
> 
> What happens if I send a forged email with some user's email address as
> FROM and use a fake key? Automatic public key collection isn't a very good
> idea, you should be *very* careful about how you handle public keys.

The idea was to collect the public keys so an authority (list admin)
could manually set their trust levels which would be necessary in strict
(b) mode in order to use a key at all.

On 28.02.2016 04:48, Abhilash Raj wrote:
>>  2. Outbound mail encryption and signature validation
>>
> 
> I would suggest you keep encryption as a part of extended goals in case of
> GSoC. You'd be surprised how many students are not able to finish their
> proposal in time.

I will try to make a realistic evaluation of what's possible in my GSoC
before i apply.

On 28.02.2016 10:30, Stephen J. Turnbull wrote:
>  >  2. Outbound mail encryption and signature validation
>  >  4. Inbound mail decryption and outbound mail signature
>
> I don't understand these pairs.  Why encrypt mail *to* the server if
> it's only going to be decrypted on the way out?  Why encrypt outgoing
> posts if they might have been read in the clear before being received?

On 28.02.2016 04:48, Abhilash Raj wrote:
> Shouldn't both be working differently? Encrypted
> emails distributed as encrypted email and signed email distributed as
> signed.

I paired them this way because outbound encryption and inbound signature
validation requires the application to manage the subscribers public
keys and inbound encryption requires the application to manage the lists
keypair so I would probably implement 1. and 2. as well as 3. and 4. at
the same time. 1-4 are part of the core functionality.
My list is badly structured.


On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> End-to-end encryption or signature or both seems to be the right
> thing.

The concept of a mailserver doesn't allow real end-to-end encryption if
each recipient uses a different keypair.
A user would have to have the public keys of all the subscribers at the
time of sending a mail to the list and encrypt the mail for each of
them. This would require modification to the client software for this to
behave like a mailinglist, especially if subscribers join or leave the list.

A method for real end-to-end mailinglists is described in
Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 [1]
but this is not what I want to do.
Another alternative would be to have a pgp proxy outside the list server
that does the re-encryption but this would not be as convenient as
having a re-encrypting listserver.

Considering that all subscribers recieve the mail and usually listserver
admins are subscribers theirselves, I think than an implementation where
the listserver recieves a copy as well definitly has some uses.
Users would have to be aware that the privacy of communication relies on
the protection of the listserver and listserver admins would have to be
aware that they need to protect the lists keypair.

On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> Out of scope for one summer IMHO.  It's not obvious wh

Re: [Mailman-Developers] Need help in installing Mailman3

[Abhilash Raj]

On 02/29/2016 12:02 AM, Saurav Kumar wrote:
> I wanted to install the new packages in a virtualenv

Then, just running 'python setup.py install' from the source or 'pip
install ' when the the virtualenv is activated should
install the package inside the virtualenv. Notice that you *don't*[1]
have to use sudo, using sudo will install it globally.

Footnotes:
1. Here I am assuming that you( the user) own the directory where the
virtualenv is.

> 
> 
> On Mon, 29 Feb 2016, 05:15 Abhilash Raj,  > wrote:
> 
> Hi Sourav,
> 
> On 02/28/2016 01:42 PM, Saurav Kumar wrote:
> > I​ want to install Mailman in a custom directory, rather than using ​
> > ​"user ​
> > ​site-package" directory which is default when using install
> without any
> > extra parameter.
> > I'm not able to use the -d and install-dir parameter. Please guide
> me what
> > i'm doing wrong
> 
> What do you mean by a custom directory? By default, setuptools is
> configured to install packages in a particular directory on each linux
> distribution (probably on OSX and Windows too, not sure about that.
> 
> However, if you want to setup mailman (or any python package) for
> development, you can try 'python setup.py develop' instead of install.
> 
> >
> > Thanks
> > Saurav
> > ___
> > Mailman-Developers mailing list
> > Mailman-Developers@python.org 
> > https://mail.python.org/mailman/listinfo/mailman-developers
> > Mailman FAQ: http://wiki.list.org/x/AgA3
> > Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/
> > Unsubscribe:
> 
> https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com
> >
> > Security Policy: http://wiki.list.org/x/QIA9
> >
> 
> --
> thanks,
> Abhilash Raj
> 
> -- 
> 
> Saurav Kumar
> Sophomore
> IIT BHU Varanasi
> 

-- 
thanks,
Abhilash Raj
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Need help in installing Mailman3

[Saurav Kumar]

I wanted to install the new packages in a virtualenv

On Mon, 29 Feb 2016, 05:15 Abhilash Raj,  wrote:

> Hi Sourav,
>
> On 02/28/2016 01:42 PM, Saurav Kumar wrote:
> > I​ want to install Mailman in a custom directory, rather than using ​
> > ​"user ​
> > ​site-package" directory which is default when using install without any
> > extra parameter.
> > I'm not able to use the -d and install-dir parameter. Please guide me
> what
> > i'm doing wrong
>
> What do you mean by a custom directory? By default, setuptools is
> configured to install packages in a particular directory on each linux
> distribution (probably on OSX and Windows too, not sure about that.
>
> However, if you want to setup mailman (or any python package) for
> development, you can try 'python setup.py develop' instead of install.
>
> >
> > Thanks
> > Saurav
> > ___
> > Mailman-Developers mailing list
> > Mailman-Developers@python.org
> > https://mail.python.org/mailman/listinfo/mailman-developers
> > Mailman FAQ: http://wiki.list.org/x/AgA3
> > Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/
> > Unsubscribe:
> https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com
> >
> > Security Policy: http://wiki.list.org/x/QIA9
> >
>
> --
> thanks,
> Abhilash Raj
>
-- 

Saurav Kumar
Sophomore
IIT BHU Varanasi
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9