Re: [Mailman-Developers] New lists at lists.mailman3.org

2016-03-18 Thread Florian Fuchs


On 18. März 2016 13:51:43 MEZ, Odhiambo Washington  wrote:
>On 18 March 2016 at 15:26, Simon Hanna 
>wrote:
>
>> On 03/18/2016 10:25 AM, Odhiambo Washington wrote:
>> > I try to login to test2 using google and I get Server Error (500).
>> >
>> > I can't use persona and I don't wanna use Yahoo!
>> citing the previous mail:
>> > Note that the login page offers Persona, Google and Yahoo for
>login, but
>> > only Persona works
>>
>> Why can't you use persona? It's working for me
>>
>
>1. Because I don't have a persona and there is really no point for me
>getting one since it's headed for closure.
>2. I have google.

You can use your Gmail address to sign in with Persona. No additional account 
necessary.

Cheers,
Florian





___
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] Should the thread-to-issue tool join threads?

2016-03-18 Thread Gurkirpal Singh
Hi, I have a little question about the GitLab integration project.

There might be some messages that were not included in the main thread
because the sender sent the message manually by setting the subject as
"RE: Something". Should the tool try to find and include these messages?
___
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

2016-03-18 Thread Abhilash Raj
Hi Jonas,

On 03/18/2016 10:29 AM, Jonas wrote:
> Thank you Stephen.
> 
> I agree with your points and I will make sure to clearly document any
> potential security pitfalls of the system for the users and to write a
> detailed and precise design plan that has special emphasis on security
> implications before I start coding this project.

Great!

> However, at the moment I'm in the middle of writing my Project Proposal.
> May I send you a draft along with personal questions?
> And/Or Abhilash Raj, may I send you those?

I guess you can upload drafts of proposal (in google docs) on GSoC's
website and we all mentors can have a look at it/comment on it if needed.

> 
> To make a first impression, I thought about writing a general blog post
> on the state of mailinglist/group communication encryption that covers
> the efforts toward encrypted lists in mailman. Could that work as a
> first impression instead of fixing a bug in mailman? The easier ones
> seem to get patched faster than I can catch up.

We need you to fix one easy bug so as to judge your capability to
actually implement the proposal that you are proposing. Although, we
have mandated one patch towards your application, a small documentation
patch and some of your previous patches to different projects
(preferably, but not required, in Python) could work. Does that sound
good? I can point you to several places we need more documentation ;-)

> Thank you again,
> Jonas
> 
> On 29.02.2016 21:49, Stephen J. Turnbull wrote:
>> 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

Re: [Mailman-Developers] Advice needed on Production MM3 install

2016-03-18 Thread Simon Hanna
On 03/16/2016 06:35 AM, Mark Sapiro wrote:
> Some of you may have seen my posts on mailman-cabal, but I am installing
> a production instance of Mailman 3 on lists.mailman3.org in order to
> support initially a Mailman 3 users list.
> 
> The first question is should it be mailman-us...@mailman3.org or
> mailman-us...@mailman3.org. The former is more of a recognition that
> Mailman 3 is now Mailman while the latter offers less possibility for
> confusion with mailman-us...@python.org. Then, I suppose it could be
> just us...@mailman3.org, but we might want to support other 'users'
> lists in the future.
The list names are the same, I guess you misspelled one.
> The next thing is I'm having much more difficulty than I anticipated,
> probably in large part because I haven't followed Postorius and
> HyperKitty development that closely. I have lots of things I think I
> should be able to do in Postorius and I can't and I don't know if the
> issue is Postorius or my installation.
> 
> I initially installed mailman-bundler from gitlab. configured it for
> production, ran buildout and set it up. My initial issue is I couldn't
> log in to Postorius at all. I had set a Django superuser, but I see
> nowhere to authenticate as that. The only logins offered were Google,
> Yahoo and Persona, and they all threw various but similar exceptions.
Postorius enables local logins by default. Hyperkitty needs you to set
USE_INTERNAL_AUTH = True
in the settings file.
Postorius has it's own login templates '/postorius/accounts/login'
where you should always be able to login using a local account.
Postorius only supports local and persona.
Hyperkitty's templates are used by default, which add yahoo and google login,
but will need tweaking the settings for local logins.

About the other login methods. I only have persona enabled and haven't used
the others. At least for google you will need to sign up for a client ID.
I
> With Abhilash's help, I got past some of that and I can now log in with
> Persona, but there are still issues with the others[1].
> 
> In the process of working through that, I cloned the head of the mailman
> branch from github and upgraded to that, but Postorius and HyperKitty
> are still what bundler installed.
Just in case you run into issues, you should probably use the git versions
of Postorius, Hyperkitty and mailmanclient as well.
> I got PostgreSQL, Postfix, openDKIM, nginx and gunicorn all configured
> and that all seems good.
> 
> In the process of working through some other issues, I enabled SSL in
> Django with certificates I got from Let's Encrypt. That has led to a
> current issue which is if a list's archiving is on, I can't post. The
> post gets shunted in archiving because somewhere in the process the
> runner tries to make an SSL connection to 127.0.0.1 and the certificate
> is only valid for lists.mailman3.org, mirror.list.org and
> mirror.mailman3.org[2]. I'm sure there must be a way to change the
> connect to use lists.mailman3.org, but I don't know it.
I ran into this issue as well. I had all of postorius and hyperkitty
secured by ssl. So the link I used in mailman-hyperkitty (archiver plugin)
started with "https"
Hyperkitty a setting MAILMAN_ARCHIVER_FROM that defines which ips are
allowed to use it's api to add to the archives. By default it only contains
localhost addresses. You will need to add your external ip addresses,
as the requests will all have your external ip.
> Then perhaps my biggest issue is I can't do any admin tasks in Postorius
> other than on my own lists. I can't create lists or domains or edit
> domains or anything like that. I even set my user record is_server_owner
> flag True, but that didn't help. I managed to do some of what I needed
> via the mailman create and mailman shell commands, but I'm sure I should
> be able to do that in Postorius, but I can't log in as superuser and it
> doesn't seem to care that I'm a server admin. Maybe I need to upgrade
> Postorius and HyperKitty.
> 
> Which is the next advice I need. I'm thinking of trying to start clean
> and I have questions.
> 
> Is it better to use bundler and then upgrade what it installed or just
> install the separate pieces and try to knit them together or should I
> maybe just upgrade Postorius and HyperKitty in place as I did the core.
> If I start clean will running the bin/mailman-post-update script
> initialize all the data or will there be residue in the PostgreSQL
> database that may cause problems.
Running mailman-post-update multiple times shouldn't cause any issues.
I like deploying things myself, so I know how to fix them if needed,
I have a running production installation using git.
(mainly because the released version of mailman doesn't support python 3.5)
It's really not that hard to setup. It's mostly just python setup.py install
or just using pip.
I have a bunch of pkgbuilds for archlinux that might be helpful if you want
to install it on your own. This one holds everything together:

Re: [Mailman-Developers] New lists at lists.mailman3.org

2016-03-18 Thread Stephen J. Turnbull
Odhiambo Washington writes:

 > Thanks, Florian, but why should I go that way when there is a link to sign
 > in with google, which I already have?

Because the mailman3.org system is in beta (to be generous).  Google
sign-in is "supposed" to work, but doesn't.  Try going through
Persona with your Google account, as Simon suggested.  Worked for me.

 > Are there people who have installed MM3 on FreeBSD? And integrated
 > with Exim?

 > I think Turnbull has his running with Exim, but on Linux.

I got it running but that was a long time ago, pre-release (and
pre-persona), and for a limited-time low-traffic list.  Since then
I've not had time to upgrade, and Postorius/HyperKitty weren't tested
at all except for mass subscribe IIRC (although I might even have done
that by mailman.client, as it was called then).

I see no reason why the Exim integration would change:
https://gitlab.com/mailman/mailman/blob/master/src/mailman/docs/MTA.rst#exim
As far as I can recall the MM3_UID and MM3_GID are no-ops, as Mailman
3 communicates entirely by sockets.  Exim has no need to know.  (The
variables are a holdover from Mailman 2 where pipes are used, so Exim
needs to run Mailman with the appropriate privileges IIRC.)

 > I'd love to have someone share their notes on installation on
 > FreeBSD.

Mailman core really shouldn't be OS-specific (except to the extent
that a supported MTA and Python are available).  All communication
takes place via (Unix-domain) sockets.

I'm not sure that things won't be a little hairier for HyperKitty and
Postorius, but again, as long as Python runs, they should work the
same on any system that supports sockets (that's one of the advantages
of the current architecture -- zeroconf, not yet, but configuration is
getting easier).

The only thing I can think of that might be vendor-specific is the
location of Mailman itself, but at this point in time I see no reason
to install it anywhere but /usr/local.

The real problems that people have are plain ol' bugs.

___
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

2016-03-18 Thread Stephen J. Turnbull
Abhilash Raj writes:

Thanks for picking this up, Abhilash!

Jonas writes:

 > > However, at the moment I'm in the middle of writing my Project Proposal.
 > > May I send you a draft along with personal questions?

If you mean do I like cats, I don't see what that has to do with
GSoC. ;-)  If you mean specific to your proposal, no, it doesn't work
that way.  Mentors aren't tutors, and your proposal isn't to one or
more potential mentors, it's to the project.  The project decides what
proposals to accept, subject to mentor availability.  The project
decides whether your design is appropriate, whether your code is
effective, complete, and so on.  Once a mentor is assigned, he or she
is responsible as the front-line delegate of the project to manage
your work, to help you with work processes, and the backstop to ensure
that technical questions are answered quickly.

On the other hand, most technology and project process questions can
be answered by any developer, and GSoC questions by any mentor.  So in
general you can post any Mailman questions here.  GSoC questions can
be asked on the GSoC "general" or "students" mailing lists, or here.
Note that everybody in open source is stretched very thin during GSoC
applications; asking questions in the right place is much more likely
to get you good answers quickly.  If you need authoritative answers on
GSoC, Stephanie and Cat monitor the GSoC lists so you will get useful
answers there.

If you're worried that other students will benefit from your questions
and our answers -- this is open source, giving others the benefit of
our work is the point of what we're doing!  It's not just altruistic;
there are mechanisms for compensating you.  You still get credit for
(1) openness itself and (2) working with us.  If somebody steals your
ball and runs off with it, they had better be just as cooperative and
open or they lose points (and either way, you still maintain an edge
due to being first in and getting things rolling).

 > > And/Or Abhilash Raj, may I send you those?
 > 
 > I guess you can upload drafts of proposal (in google docs) on
  > GSoC's website and we all mentors can have a look at it/comment on
 > it if needed.

Please do register and upload a draft as soon as possible, even if
very incomplete.  The Google SoC system is all-new this year, and has
been distinctly slow the last day or two since student applications
opened.  I don't expect it to crash, but if it does, *it is not an
excuse for not being registered*!  That's Google policy; if you don't
have an application on file by the deadline date, you *cannot* become
a GSoC intern.  We have zero input to this policy.  OTOH, we can work
around incompleteness in the event of system problems.

I haven't seen the student UI, but I've heard that you can mark your
proposal "draft" (or maybe you have to mark it "final", which amounts
to the same thing).  So you don't have to worry that an incomplete
draft will count against you (in Mailman, we don't make judgments
until applications close in any case).

If the draft seems *wrong* in some place, we'll let you know about
that quickly.  If it's still incomplete on 3/22 or so, we'll ping you
about that.

 > > To make a first impression, I thought about writing a general
 > > blog post on the state of mailinglist/group communication
 > > encryption that covers the efforts toward encrypted lists in
 > > mailman.

That's a good idea in itself, but not a substitute for a patch.

 > > Could that work as a first impression instead of fixing
 > > a bug in mailman? The easier ones seem to get patched faster than
 > > I can catch up.
 > 
 > We need you to fix one easy bug so as to judge your capability to
 > actually implement the proposal that you are proposing.

That's somewhat inaccurate.  The reasons you need to fix a *Mailman*
bug are

1.  You have to post a merge request, which means
2.  you know a little bit about our Gitlab repos, and
3.  a little bit about Gitlab, and
4.  have a Gitlab account.

That might not be a problem for you, but we've had issues in the past
where the student floundered for a couple weeks midproject with the
registration and submission procedure.

To judge implementation ability, other projects you've done or
contributed to are valid evidence, of course, as long as you can point
us to the code.

 > I can point you to several places we need more documentation ;-)

I don't care who does it (Abhilash direct-to-tracker, or Abhilash-to-
Jonas-to-tracker), but please make sure all are filed on the tracker.

___
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] New lists at lists.mailman3.org

2016-03-18 Thread Stephen J. Turnbull
Barry Warsaw writes:

 > I noticed some weirdness and crashes in Postorius and will submit bugs as
 > appropriate.

Bugs go where?  That is, these could be Postorius bugs or just kinks
in Mark's configuration so far (ok, crashes == uncaught Exceptions, I
hope?! aren't configuration bugs, they're real bugs).

For now I'll submit @Postorius, at least some of the weirdness I see
is clearly Postorius-level.

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