Debian-LTS has issued an advisory today (September 2): http://lwn.net/Alerts/699147/ The issue is fixed upstream in 2.1.23: https://mail.python.org/pipermail/mailman-announce/2016-August/000226.html A patch is attached to this bug: https://bugs.launchpad.net/mailman/+bug/1614841 Mageia 5 is also affected.
Whiteboard: (none) => MGA5TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package
Assignee: bugsquad => pkg-bugsCC: (none) => marja11
Changed version from cauldron to 5 as this applies to both. mailman-2.1.23-1.mga6 has been uploaded for cauldron/6.
Version: Cauldron => 5CC: (none) => mramboWhiteboard: MGA5TOO => (none)
Patched package uploaded for Mageia 5. Advisory: ======================== Updated mailman package fixes security vulnerability: Cross-site request forgery (CSRF) vulnerability in the user options page in GNU Mailman 2.1.x before 2.1.23 allows remote attackers to hijack the authentication of arbitrary users for requests that modify an option, as demonstrated by gaining access to the credentials of a victim's account (CVE-2016-6893). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6893 https://www.debian.org/security/2016/dsa-3668 ======================== Updated packages in core/updates_testing: mailman-2.1.20-3.mga5 from mailman-2.1.20-3.mga5.src.rpm
Assignee: pkg-bugs => qa-bugs
Potential testing procedure at: https://bugs.mageia.org/show_bug.cgi?id=8067
Whiteboard: (none) => has_procedure
(In reply to Mike Rambo from comment #4) > Potential testing procedure at: > https://bugs.mageia.org/show_bug.cgi?id=8067 Specifically, https://bugs.mageia.org/show_bug.cgi?id=8067#c24
CC: (none) => lewyssmith
This may help in testing. It "Works For Me". Mailman requires: httpd (or other web server) Make sure you have something set for fqdn. For this purpose it is sufficient to just add a /etc/hosts entry. your.box.ip.address mmtest.example.com mmtest Reboot to take effect. urpmi mailman Check the configuration in mm_cfg.py. [choose your editor] /usr/lib64/mailman/Mailman/mm_cfg.py You should see whatever you set for fqdn represented on the lines: DEFAULT_EMAIL_HOST = 'example.com' DEFAULT_URL_HOST = 'mmtest' If you install mailman before setting fqdn these will need to be adjusted manually. Restart the web server to pick up config changes from the mailman install. systemctl restart httpd From cli on the box running mailman: newlist testlist (and answer the questions - will create a test list) Browse to http://localhost/mailman (or from another machine http://your.box.ip.address/mailman). You should see the mailman front page. But unless DNS is properly set up and you are addressing the host by correct dns name you probably won't see any lists. However the testlist should be there. Click the 'list admin overview page' hyperlink. On the browser url bar append /testlist to whatever is there and press enter. You should be asked for the list's admin password (which is whatever you provided above). On that page give it a terse phrase identifying the list in the fourth field. Update at the bottom and logout. A hack to bypass the dns requirement to see the list is to edit /usr/lib64/mailman/Mailman/mm_cfg.py again. Add to the bottom of the file. VIRTUAL_HOST_OVERVIEW = Off If you then click the 'Overview of all [example.com] mailing lists' hyperlink you should see your list. This does not test actual mailing features but should be sufficient to establish basic function.
64-bit real hardware Tried out Mike's works-for-me instructions and they worked for me. $ newlist testlist newlist: Command not found. $ sudo newlist testlist Enter the email of the person running the list: tarazed25@gmail.com Initial testlist password:<whatever> Hit enter to notify testlist owner... $ Modified some of the entries in testlist after creating a password and logging in. The list edits were preserved over logout/login. Had a go at subscribing from another machine on the LAN - not sure how that went. The application said it would be in touch. Left the files in place and installed the update. Is that OK? Restarted httpd. Browser address = localhost/mailman -> localhost/mailman/admin.cgi/testlist/general Edited the introductory description field and logged out and in again. The changes were preserved. Moved to another machine and accessed testlist via the <remote host>/mailman address.
CC: (none) => tarazed25
Trying Mageia 5 x64 Many thanks to Mike for his Comment 6 guidance. Added entries as suggested to my only /etc/hosts entry: $ cat /etc/hosts 127.0.0.1 localhost.localdomain localhost mmtest.example.com mmtest but wonder whether mailList advice along the lines of: 127.0.0.2 mail.home.test mail would have been more appropriate. See later. Re-booted. # urpmi mailman mailman-2.1.20-2.mga5 python-GnuPG-Interface-0.3.2-17.mga5 Create a new, unpopulated mailing list. Usage: /usr/sbin/, lots of explanatory output.ewlist [options] [listname [listadmin-addr [admin-password]]] Options: etc etc, lots of explanatory output. .................... No such list "mailman" warning: %post(mailman-2.1.20-2.mga5.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for mailman-2.1.20-2.mga5 ??? # tail -6 /usr/lib64/mailman/Mailman/mm_cfg.py ################################################## # Put YOUR site-specific settings below this line. DEFAULT_EMAIL_HOST = 'localdomain' DEFAULT_URL_HOST = 'localhost.localdomain' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) MTA = 'Postfix' I will try two /etc/hosts lines, remove mailman, and re-start from scratch.
Trying Mageia 5 x64 real H/W continued. $ cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 127.0.0.2 mmtest.example.com mmtest # urpmi mailman $MIRRORLIST: media/core/release/mailman-2.1.20-2.mga5.x86_64.rpm ... Exactly the same result as before, error & mm_cfg.py included. Will re-try with just 127.0.0.1 mmtest.example.com mmtest.
Trying Mageia 5 x64 real H/W continued. Took out mailman then /etc/mailman.rpmsave, edited /etc/hosts as below, re-boot. $ cat /etc/hosts 127.0.0.1 mmtest.example.com mmtest # urpmi mailman gave exactly the same O/P as previously, error & mm_cfg.py included: # tail -4 /usr/lib64/mailman/Mailman/mm_cfg.py DEFAULT_EMAIL_HOST = 'localdomain' [?] DEFAULT_URL_HOST = 'localhost.localdomain' [?] add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) MTA = 'Postfix' Hmm. Gave up, edited that to: DEFAULT_EMAIL_HOST = 'example.com' DEFAULT_URL_HOST = 'mmtest' # systemctl restart httpd # newlist testlist and answered the couple of questions: - an admin e-mail address - testlist password. Browse to http://127.0.0.1/mailman and got the 1st Welcome screen: "127.0.0.1 Mailing Lists Welcome! There currently are no publicly-advertised Mailman mailing lists on 127.0.0.1. To visit the general information page for an unadvertised list, open a URL similar to this one, but with a '/' and the list name appended. List administrators, you can visit the list admin overview page [http://127.0.0.1/mailman/admin.cgi] to find the management interface for your list." Click the 'list admin overview page' hyperlink -> 2nd welcome page: "127.0.0.1 mailing lists - Admin Links Welcome!" etc as above. Append '/testlist' to whatever is in the browser URL bar and press enter, displays the "Testlist Administrator Authentication" screen with the list password field. Enter that, click 'Let me in' shows the "Testlist mailing list administration General Options Section" page, lots of potential entry fields. In the fourth field give it a terse phrase identifying the list. Update at the bottom; and logout (top). A hack to bypass the dns requirement to see the list: Edit /usr/lib64/mailman/Mailman/mm_cfg.py again; add to the bottom of the file: VIRTUAL_HOST_OVERVIEW = Off # tail -5 /usr/lib64/mailman/Mailman/mm_cfg.py DEFAULT_EMAIL_HOST = 'example.com' DEFAULT_URL_HOST = 'mmtest' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) MTA = 'Postfix' VIRTUAL_HOST_OVERVIEW = Off Going to just http://127.0.0.1/mailman/ shows a revised 1st Welcome screen: "mmtest Mailing Lists" with Testlist directly shown; which shows its entry "Testlist -- mailman testlist" page. So far so good (except for /etc/hosts dilemma). Will try the update tomorrow.
Please note that https://bugs.mageia.org/show_bug.cgi?id=19386 is relevant to the post install scriptlet error.
(In reply to Mike Rambo from comment #11) > Please note that https://bugs.mageia.org/show_bug.cgi?id=19386 is relevant > to the post install scriptlet error. Thanks for pointing this out. AFTER the update: mailman-2.1.20-3.mga5 This passed without incident. Restarted httpd. The Mailman system seemed to behave just the same as previously. I tried removing the last "VIRTUAL_HOST_OVERVIEW = Off" line in /usr/lib64/mailman/Mailman/mm_cfg.py and re-started httpd, but it seemed to need a reboot to see the effect: testlist no longer shown on Welcome screens, have to append it to the http://localhost/mailman/admin.cgi/ as originally to get its login screen. To simplify things for the future, I tried re-setting: # cat /etc/hosts 127.0.0.1 localhost.localdomain localhost # hostname localhost.localdomain [never altered because "it is sufficient to just add a /etc/hosts entry"]. and the config file to its install defaults: DEFAULT_EMAIL_HOST = 'localdomain' DEFAULT_URL_HOST = 'localhost.localdomain' ... and re-booted, and the web interface works fine from http://localhost/mailman/ Did I ever need to change the hosts file? ---------------------------------------- We have not looked at the server... It is in the list of services to start at boot, but not shown running. Trying to start it does not work. # systemctl status mailman.service â mailman.service - GNU Mailing List Manager Loaded: loaded (/usr/lib/systemd/system/mailman.service; enabled) Active: failed (Result: exit-code) since Maw 2016-10-04 22:22:04 CEST; 16min ago Process: 1689 ExecStart=/usr/lib64/mailman/bin/mailmanctl -s start (code=exited, status=1/FAILURE) Process: 1679 ExecStartPre=/bin/chmod 660 /var/log/mailman/error (code=exited, status=0/SUCCESS) Process: 1664 ExecStartPre=/bin/chown mail:mail /var/log/mailman/error (code=exited, status=0/SUCCESS) Process: 1658 ExecStartPre=/bin/touch /var/log/mailman/error (code=exited, status=0/SUCCESS) Process: 1619 ExecStartPre=/usr/bin/install -m644 -o root -g root /usr/lib64/mailman/cron/crontab.in /etc/cron.d/mailman (code=exited, status=0/SUCCESS) Hyd 04 22:22:04 localhost.localdomain mailmanctl[1689]: Site list is missing:... Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service: control pr... Hyd 04 22:22:04 localhost.localdomain systemd[1]: Failed to start GNU Mailing... Hyd 04 22:22:04 localhost.localdomain systemd[1]: Unit mailman.service entere... Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service failed. -------------------------- Does this matter? Can we OK this update just on the basis of the functional web interface?
(In reply to Lewis Smith from comment #12) > ---------------------------------------- > > Hyd 04 22:22:04 localhost.localdomain mailmanctl[1689]: Site list is > missing:... > > > Hyd 04 22:22:04 localhost.localdomain systemd[1]: mailman.service failed. > -------------------------- > Does this matter? Can we OK this update just on the basis of the functional > web interface? Not sure about the answer to your last question but it looks like the service problem is due to the post install scriptlet error. Among the things that scriptlet does is to create the site list mentioned above. Without that site list, the mailman service does not start (this is documented in mailman docs). It would be interesting to find out whether the service would start if you manually did a "newlist mailman" to add the site list ('mailman' is hard coded to be the site list name). I don't have a good handle on what will and will not work without the fqdn set up but it is pretty certain some things will be broken without it. Claire's original test procedure mentioned having it. Earlier today I set up a box with a full fqdn including support from an internal dns server and /etc/hosts file. When I installed mailman in that environment there was no post install scriptlet error and everything has worked. But regarding that last question, unless you go to the lengths of setting up postfix (or sendmail) to handle the mailing you will never be able to test *all* of the mailman functions. I am new enough that I don't know how Mageia handles QA for such a circumstance. There is more than one part of that post installation scriptlet that does not work. The aliases part of it did not work in the test environment I used today and it didn't even generate an error. The aliases simply were not added. Hope this helps.
Finishing M5-64 Mike: thanks for your Comment 13 elaboration. Following the Comment 6 procedure, with the Mailman update already installed, I edited the two relevant files with what I think is my real IP address: /etc/hosts [but *not* /etc/host] 127.0.0.1 localhost.localdomain localhost 88.127.87.5 mmtest.example.com mmtest /usr/lib64/mailman/Mailman/mm_cfg.py DEFAULT_EMAIL_HOST = 'example.com' DEFAULT_URL_HOST = 'mmtest' Re-booted. Mailman still worked from a browser, but # systemctl status mailman.service still showed failure as per Comment 12. So tried as suggested in Comment 13; # newlist mailman # systemctl restart httpd [Just in case it matters] # systemctl restart mailman.service [Necessary; without this, it still failed] # systemctl status mailman.service Bingo! â mailman.service - GNU Mailing List Manager Loaded: loaded (/usr/lib/systemd/system/mailman.service; enabled) Active: active (running) since Iau 2016-10-13 20:23:53 CEST; 6s ago ... Hyd 13 20:23:53 localhost.localdomain mailmanctl[11117]: Starting Mailman's m... So in line with Len's findings, am OKing this update at last.
Whiteboard: has_procedure => has_procedure MGA5-64-OK
Revisiting this bug to make sure I can retrace my steps. Started with a clean sheet on a 64bit vbox. Tried the localhost/mailman web interface and could not create a mail list - the message indicated that I was not authorized to create lists - unsure what password was required - tried a couple or three possibilities - all failed. Finally went back to the cli and used $ newlist alkaid and was then able to locate the list on the administrator page and modify it. Starting the mailman service failed, as it did for Lewis. Shall try the 'newlist mailman' command after updating.
Am validating this update with just one OK because we are hard pressed. Apparently the advisory (when I tried to create it) was already in place, though not marked thus in the bug; which I have done.
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK advisoryCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0343.html
Status: NEW => RESOLVEDResolution: (none) => FIXED