Mailman-coders November 2015

mailman-coders@python.org

7 participants
39 discussions

[Bug 757062] [NEW] Content filtering can remove the headers from a message/rfc822 part.

by Mark Sapiro

Public bug reported: If Content filtering accepts both message/rfc822 and multipart/alternative MIME parts, and a message/rfc822 part contains a message whose content type is multipart/alternative and collapse_alternatives is Yes, the headers of the message in the message/rfc822 part will be lost. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/757062 Title: Content filtering can remove the headers from a message/rfc822 part.

4 years, 3 months

[Bug 775294] [NEW] Set lifetime for input forms

by Tokio Kikuchi

*** This bug is a security vulnerability *** Private security bug reported: We may have to set lifetime for input forms because of recent activities on cross-site request forgery (CSRF). The form lifetime is successfully deployed in frameworks like web.py or plone etc. Proposed branch lp:~tkikuchi/mailman/form-lifetime implement lifetime in admin, admindb, options and edithtml interfaces. Other forms like create and rmlist have confirmation by password thus are safe regarding CSRF. The form generation time is set by a hidden parameter whose value is calculated following the mailman cookie algorithm. The default lifetime is set 1 hour in Default.py thus configurable by a site administrator. If a password is set in request, authorization cookie is discarded so the password authentication is forced. Wget tricks to manage list in FAQ can be used as they are now. ** Affects: mailman Importance: Undecided Status: New ** Branch linked: lp:~tkikuchi/mailman/form-lifetime -- You received this bug notification because you are a member of Mailman Coders, which is a direct subscriber. https://bugs.launchpad.net/bugs/775294 Title: Set lifetime for input forms

5 years

[Bug 1445764] [NEW] "The executable /usr/bin/python3.4 does not exist" error when Installling Mailman 3 on Centos 7

by Danil Smirnov

Public bug reported: Short summary: when installing Mailman 3 onto new Centos 7 box using manual at page http://mailman-bundler.readthedocs.org/en/latest/ after step (venv)[root@host mailman-bundler]# pip install zc.buildout (venv)[root@host mailman-bundler]# buildout getting the error: --- Installing mailman. The executable /usr/bin/python3.4 (from --python=/usr/bin/python3.4) does not exist /tmp/tmpePyrQ3/run: line 2: /usr/local/src/mailman-bundler/venv-3.4/bin/pip: No such file or directory While: Installing mailman. --- Now in details: Fresh new CentOS Linux release 7.1.1503 (Core) installed as kvm guest. System python package installed: python-2.7.5-16.el7.x86_64 Python 3.4.3 was installed by commands: [root@host ~]# cd /usr/local/src [root@host src]# curl -O https://www.python.org/ftp/python/3.4.3/Python-3.4.3.tgz [root@host src]# tar -xvzf Python-3.4.3.tgz [root@host src]# cd /usr/local/src/Python-3.4.3 [root@host Python-3.4.3]# ./configure --enable-shared --prefix=/usr/local LDFLAGS="-Wl,-rpath /usr/local/lib" [root@host Python-3.4.3]# make [root@host Python-3.4.3]# make altinstall Virtualenv was installed from package python-virtualenv.noarch 0:1.10.1-2.el7 with dependant python-devel.x86_64 0:2.7.5-16.el7 Then everything was don according http://mailman-bundler.readthedocs.org/en/latest/ until the error mentioned above occurred. When I did (venv)[root@host mailman-bundler]# ln -s /usr/local/bin/python3.4 /usr/bin/python3.4 I've got another error: --- (venv)[root@host mailman-bundler]# buildout Develop: '/usr/local/src/mailman-bundler/.' warning: no files found matching '*.in' under directory 'mailman_bundler' warning: no files found matching '*.in' under directory 'deployment' warning: no files found matching 'deployment/mailman-web.logrotate.conf' Updating mailman-web. Updating main. Installing mailman. Running virtualenv with interpreter /usr/bin/python3.4 Using base prefix '/usr/local' New python executable in /usr/local/src/mailman-bundler/venv-3.4/bin/python3.4 Also creating executable in /usr/local/src/mailman-bundler/venv-3.4/bin/python Failed to import the site module Traceback (most recent call last): File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site.py", line 67, in <module> import os File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/os.py", line 616, in <module> from _collections_abc import MutableMapping ImportError: No module named '_collections_abc' ERROR: The executable /usr/local/src/mailman-bundler/venv-3.4/bin/python3.4 is not functioning ERROR: It thinks sys.prefix is '/usr/local/src/mailman-bundler' (should be '/usr/local/src/mailman-bundler/venv-3.4') ERROR: virtualenv is not compatible with this system or executable /tmp/tmpTl6JgC/run: line 2: /usr/local/src/mailman-bundler/venv-3.4/bin/pip: No such file or directory While: Installing mailman. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1946, in main getattr(buildout, command)(args) File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 626, in install installed_files = self[part]._call(recipe.install) File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1370, in _call return f() File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 56, in install self.execute() File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 69, in execute run_commands(cmds, self.shell) File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 39, in run_commands check_call('%s %s' % (shell, tmpfile), shell=True) File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command 'sh /tmp/tmpTl6JgC/run' returned non-zero exit status 127 --- ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1445764 Title: "The executable /usr/bin/python3.4 does not exist" error when Installling Mailman 3 on Centos 7 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1445764/+subscriptions

5 years, 4 months

[Bug 1457271] [NEW] HTTP 500 error when saving changes to Message Acceptance settings

by Josh Farwell

Public bug reported: Hello, I installed Mailman 3 and Postorius on CentOS 7, via the packages available at this repo: https://repos.fedorapeople.org/repos/abompard/hyperkitty/el-7/x86_64/ I am using the default Postorius configuration. I am running Postorius using the provided development Django project from bzr. I have configured a domain that isn't real and a test list. Mailman has access to an outgoing MTA but the MTA can't send mail back via LMTP, at least at the moment. I encountered an error when I attempted to change the test list's settings for Message Acceptance. When I try to save my change in settings, for any setting on that page, I get an error. I was able to successfully change settings on that page (setting default_member_action to "accept", specifically) by using the Python REST client. I directly changed the value and ran .save() and everything looked correct and there were no errors. This is the error in the Postorius log: [20/May/2015 19:59:35] "POST /postorius/lists/testlist.mail.local/settings/message_acceptance HTTP/1.1" 500 78853 This is the output from mailman.log: May 20 20:59:35 2015 (12584) 127.0.0.1 - - "PATCH /3.0/lists/testlist(a)mail.local/config HTTP/1.1" 400 2 Here is the trace output from the error: ******* Environment: Request Method: POST Request URL: http://127.0.0.1:8000/postorius/lists/testlist.mail.local/settings/message_… Django Version: 1.6.11 Python Version: 2.7.5 Installed Applications: ('django.contrib.auth', 'django.contrib.messages', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.staticfiles', 'postorius', 'django_browserid') Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware') Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 112. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/postorius/auth/decorators.py" in wrapper 58. return fn(*args, **kwargs) File "/usr/lib/python2.7/site-packages/postorius/views/list.py" in list_settings 787. except HTTPError as e: Exception Type: UnboundLocalError at /postorius/lists/testlist.mail.local/settings/message_acceptance Exception Value: local variable 'HTTPError' referenced before assignment ********* Let me know what other information you need, or how I can help diagnose this issue. ** Affects: postorius Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1457271 Title: HTTP 500 error when saving changes to Message Acceptance settings To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1457271/+subscriptions

5 years, 5 months

[Bug 1104498] [NEW] Member contact requests

by Kẏra

Public bug reported: When configured to hide email addresses. a mailman user should be able to contact someone else by using a request contact form a profile page representing a user. This form would email the recipient of the request a short message explaining who is trying to get in contact, and the email address of the user requesting contact. ** Affects: mailman Importance: Undecided Status: New ** Tags: wishlist -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1104498 Title: Member contact requests To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1104498/+subscriptions

5 years, 5 months

[Bug 1450469] [NEW] install step using buildout fails with os.path.walk error

by Billy Glynn

Public bug reported: (venv)[root@lists mailman-bundler-3.0.0]# buildout Creating directory '/usr/local/src/mailman-bundler-3.0.0/bin'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/parts'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/eggs'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/develop-eggs'. Develop: '/usr/local/src/mailman-bundler-3.0.0/.' warning: no files found matching '*.in' under directory 'mailman_bundler' warning: no files found matching '*.in' under directory 'deployment' warning: no files found matching 'deployment/mailman-web.logrotate.conf' Getting distribution for 'djangorecipe'. Got djangorecipe 1.11. Getting distribution for 'Django'. warning: no previously-included files matching '__pycache__' found under directory '*' warning: no previously-included files matching '*.py[co]' found under directory '*' Got Django 1.8. Getting distribution for 'zc.recipe.egg>=2.0.0a3'. Got zc.recipe.egg 2.0.1. Getting distribution for 'collective.recipe.cmd'. warning: no previously-included files matching '*.pyc' found anywhere in distribution Got collective.recipe.cmd 0.10. Getting distribution for 'z3c.recipe.filetemplate'. Got z3c.recipe.filetemplate 2.2.0. While: Installing. Getting section templates. Initializing section templates. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1946, in main getattr(buildout, command)(args) File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 510, in install [self[part]['recipe'] for part in install_parts] File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 510, in <listcomp> [self[part]['recipe'] for part in install_parts] File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1098, in __getitem__ options._initialize() File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1202, in _initialize self.initialize() File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1211, in initialize self.recipe = recipe_class(buildout, name, self) File "/usr/local/src/mailman-bundler-3.0.0/eggs/z3c.recipe.filetemplate-2.2.0-py3.4.egg/z3c/recipe/filetemplate/__init__.py", line 145, in __init__ os.path.walk( AttributeError: 'module' object has no attribute 'walk' ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1450469 Title: install step using buildout fails with os.path.walk error To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1450469/+subscriptions

5 years, 6 months

[Bug 1517446] [NEW] Please add multipart/signed to DEFAULT_PASS_MIME_TYPES

by carloslp

Public bug reported: Mailman tarballs contain a Defaults.py file with this configuration: DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain'] NOTE: I don't know how this file is generated, I found it on the tarballs but not on the repository So, when someone enables filtering on a mailing list by mime-type, the default is to filter all emails not matching any of those 3 mime-types. This list of default mime types allowed misses to include "multipart/signed". Therefore, this is unfortunately filtering any "multipart/signed" emails. "multipart/signed" is defined on RFC 3156 <https://tools.ietf.org/html/rfc3156> and is the recommended way of signing mails with GPG. See http://wiki.gnupg.org/SignatureHandling The proposed change is to modify that default configuration to: DEFAULT_PASS_MIME_TYPES = ['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain', ] This default causes trouble to people that signs their mails with GPG. I already had problems due to this default on the Alioth Debian mailing lists and on the WebKit mailing lists because the admin enabled filtering by mime-type and didn't changed the default. Please, change this default by adding at least 'multipart/signed' to the list of types allowed. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1517446 Title: Please add multipart/signed to DEFAULT_PASS_MIME_TYPES To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1517446/+subscriptions

5 years, 6 months

[Bug 1279980] [NEW] Some forms in list admin interfaces use absolute links in form action

by Vitor Choi Feitosa

Public bug reported: Some forms in admin interface, like the one on list member management -- https://HOSTNAME/mailman/admin/somelist/members -- , use absolute links as the form action url. POST data then gets transmitted in the clear because that absolute link points to http instead of https address. I'm running mailman 2.1.14 ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1279980 Title: Some forms in list admin interfaces use absolute links in form action To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1279980/+subscriptions

5 years, 7 months

[Merge] lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client

by Rajeev S

Rajeev S has proposed merging lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli/+merge/23… GSoC project "Mailman CLI" The branch contains the Mailman CLI shell as well as the command line tools built as a part of the GSoC 2014, Under the mentors Stephen J Turnbull, Abhilash Raj and Barry Warsaw. -- https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli/+merge/23… Your team Mailman Coders is requested to review the proposed merge of lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client.

5 years, 7 months

[Bug 1491187] [NEW] mailmanctl check_privs should check effective uid, not real uid

by Mark Sapiro

Public bug reported: Situations can arise where mailmanctl is running with an effective uid of 'mailman' and a real uid of 'root'. Such a situation is if logrotate does 'su mailman mailman' to rotate mailman's logs and then invokes 'mailmanctl reopen' in a postrotate script. In this case, mailmanctl gets its real uid which is 'root' and then tries to do os.setgroups, but the effective uid is 'mailman' which doesn't have permission to set groups. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1491187 Title: mailmanctl check_privs should check effective uid, not real uid To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1491187/+subscriptions

5 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders November 2015