Mailman 3 September 2006 - Mailman-Developers

Re: [Mailman-Developers] [Mailman-Users] RELEASED: Mailman 2.1.9
by Barry Warsaw 13 Sep '06

13 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 13, 2006, at 10:10 AM, Ralf Hildebrandt wrote: > The download link on http://www.gnu.org/software/mailman/download.html > pointing to http://www.list.org/mailman.tar.gz doesn't work. > > The download link on http://www.gnu.org/software/mailman/download.html > pointing to http://ftp.gnu.org/gnu/mailman/ > lacks 2.1.9 Due to a recent server move and bandwidth cap, we can no longer provide tarball downloads from list.org. Also, because of gnu.org's ftp upload procedure, it sometimes lags behind SourceForge. Your best bet immediately is to get it from SF. I've updated the download.html page to explain these issues. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRQgYT3EjvBPtnXfVAQLWqgQAth4R8JC313TxhXlNBx1maJiYZWJVA9Qg 6IUmlhrAetCFHzIWArXDKncLE+s85iOJg24eFroiQwGTw3a7tcNMkaG1vCa++E7R bl4phJ2BB0xnpDi0lKe/f5Wt8ewjNEuUwLDFImFFJguKZEMl+4RUrHo9awL19R/K HLqaksjmCeU= =UyOs -----END PGP SIGNATURE-----

1 0

RELEASED: Mailman 2.1.9
by Barry Warsaw 13 Sep '06

13 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the GNU Mailman development team, I'm please to announce GNU Mailman 2.1.9. This is primarily a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.9 also contains support for two new languages: Arabic and Vietnamese. Mailman is free software for managing email mailing lists and e- newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, including download links, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman A more detailed change list is included below. Enjoy, - -Barry 2.1.9 (12-Sep-2006) Security - A malicious user could visit a specially crafted URI and inject an apparent log message into Mailman's error log which might induce an unsuspecting administrator to visit a phishing site. This has been blocked. Thanks to Moritz Naumann for its discovery. - Fixed denial of service attack which can be caused by some standards-breaking RFC 2231 formatted headers. CVE-2006-2941. - Several cross-site scripting issues have been fixed. Thanks to Moritz Naumann for their discovery. CVE-2006-3636 - Fixed an unexploitable format string vulnerability. Discovery and fix by Karl Chen. Analysis of non-exploitability by Martin 'Joey' Schulze. Also thanks go to Lionel Elie Mamane. CVE-2006-2191. Internationalization - New languages: Arabic, Vietnamese. Bug fixes and other patches - Fixed Decorate.py so that characters in message header/footer which are not in the character set of the list's language are ignored rather than causing shunted messages (1507248). - Switchboard.py - Closed very tiny holes at the upper ends of queue slices that could result in unprocessable queue entries. Improved FIFO processing when two queue entries have the same timestamp. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRQgPGnEjvBPtnXfVAQIVoQP/R2DffgpcPMzUrsef+ZEcYUeuQ1mOcol2 Z2+iQiHkCx6SP2B/NzOzqMQybvQAAe/TzJWzcfqDDoDDdF+vhJH+kkQIuRwHc5jd +TDF1NOUBegTyxQnoyCHVQddcVNMg9HTTkdwHuvE8MhP1gNuHEnefxf2wbf5+hRq h5/qlBiANn0= =VCTA -----END PGP SIGNATURE-----

1 0

create.py: passing form values by URL
by Pierre-Marc Fournier 11 Sep '06

11 Sep '06

Hello, At our site, we have a web page with a form that users fill to request a new mailing list. If that mailing list gets approved, the admins use Mailman's create.py to effectively create it. A trivial patch allows the approval system (or any script) to pass the list name, owner, etc to create.py via the url, and have the create form already filled with those values, leaving only the password for the administrators to enter. This removes the need for a lot of copy-pasting into the create.py form and saves time. Here is the patch. I suggest that it be integrated in Mailman, as it would enable everyone to use a similar system easily. pmf --- create.py.orig 2006-08-23 12:48:15.213282750 -0400 +++ create.py 2006-08-23 13:39:24.585106500 -0400 @@ -58,7 +58,7 @@ request_creation(doc) else: # Put up the list creation request form - request_creation(doc) + request_creation(doc, cgidata) doc.AddItem('<hr>') # Always add the footer and print the document doc.AddItem(_('Return to the ') +

2 1

Patches for security issues in 2.1.9rc1
by Albert Chin 11 Sep '06

11 Sep '06

We'd like to create a patch on top of 2.1.8 for the security issues in 2.1.9rc1. For the log injection vulnerability, we applied a diff of revisions 7822-7918 for Mailman/Utils.py from the Release_2_1-maint branch. For CVE-2006-3636, we applied a diff of revisions 7975-8001 from the Release_2_1-maint branch. What revisions contain the patch for CVE-2006-2941? - Fixed denial of service attack which can be caused by some standards-breaking RFC 2231 formatted headers. CVE-2006-2941. -- albert chin (china(a)thewrittenword.com)

2 2

Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)
by Laura Carlson 11 Sep '06

11 Sep '06

--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > Thanks very much for your feedback, Laura! I am something of a > standards fanatic; all the pages I've re-written so far have made > heavy use of label (although I use the implicit label where > possible), fieldset, legend, thead & tbody and the title attribute > to provide as much support for assistive technologies and > alternative renderings as I can. Wonderful news to hear that you support accessibility and web standards, Ethan. Yes, fieldset, legend, thead, tbody and the title attributes are very important for structural markup. > Once I have a clear idea what form elements will be where, I am also > going to add tabindex and accesskey attributes to the form elements. I would like to mention a few things regarding implicit labels, accesskeys, and tabindex. LABELS The W3C identifies two different types of labels: implicit and explicit [1]. Basically, the difference is that implicit labels are an older, (deprecated in WCAG 2.0) technique that wrap around their target field elements; explicit labels use the for attribute to indicate which form element they describe (that value of the for attribute is the id of the element it describes. I would caution against using implicit labels. Explicit association is preferable. WCAG 1.0 12.4 advises web developers to "Associate labels explicitly with their controls."[2] It also says in section 508: "Experience has shown that implicit labeling should be avoided for two reasons. First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing. Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.[3]" For an illustration of this visit Roger Hudson's Web Essential 05 Association Examples [4]. If you use explicit labels, you're specifically providing information about each form element. Each form control should have its own LABEL. Add the FOR attribute to tie the LABEL to the form control's ID attribute. ACCESSKEYS Something to be aware of is that the current opinion of many accessibility experts is that accesskeys mostly work against accessibility. Because of the many conflicts, defining accesskeys seems to be a waste of time unless you are designing for a controlled environment such as an intranet. Joe Clark suggests that there are at least 36 characters that can be used for accesskey attributes [5]. However, John Foliot's and Derek Featherstone's [6] [7] unofficial survey/research concluded that there really are no useful access keys not already reserved by some application or other. When you take internationalization issues into account, it becomes pretty much of a hopeless cause. Part of this is that browsers by default don't indicate the accesskey assignments or tabbing order. No one argues with the idea behind accesskey, and it's usefulness. But given the current state of affairs, and the potential for confusion and/or conflict with various adaptive technologies, they have issues. So... Based on the existing issues I usually advise developers to not use accesskeys. However, best practice is that IF accesskeys are used: - Always supply a legend that defines the accesskeys. - Make sure this legend is on or available from every page on the site...perhaps in an accessibility statement. - Supply title attributes on any accesskeys used. - Keep the number of accesskeys to a minimum. - Test to make sure that accesskeys help usability more than they hinder accessibility. TABINDEX If you have a logical page design tabindex isn't usually necessary. By default, with no tabindex attributes present, the browser will tab through elements in the order in which they appear in the source code. Using just one tabindex for the first field like you did for the exercise isn't bad, but just having a sensible natural order to start with, meets WCAG requirements for HTML documents. If the tabindex attribute is not assigned to all fields, JAWS first moves through the items with a tabindex assigned, then moves through the other form fields and links in the order they appear on the page. You can usually lighten your HTML and usually forego tabindex. But if there is something very weird with link or form presentation so they don't function in a sensible order it can be helpful to have a tabindex. In any event I suggest it may be better to avoid having a weird ordering in HTML. If tabbing needed to come in anything but their natural order, I think I would probably regard my document structure as flawed and would rework it. When a form is well structure, and still reflects that structure when styles are turn off, the tab flow is often the same with or without coding tabindex. If that is the case, don't bother coding it when tab order is simple and clear. The W3C checkpoint [8] that actually refers to tabindex essentially says specify tab order via the tabindex attribute or ensure a logical page design. Often people seem to forget about the logical tab order that almost always exists and is reasonable. In fact, I'd say you have to work pretty hard to actually need to go outside the logical order that naturally exists within standards-based sites. Further, when people do implement tabindex, sometimes it breaks expected interaction because the order is either non-intuitive or it is completely out of line with where you think you are headed next. In my experience tabindex just makes forms more annoying to use. In most cases I'd rather web developers just let the browser get on with working out the tab order and stop trying to guess where the user wants to tab to. Ethan, thanks for all of your hard work. All the best, Laura [1] http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#label [2] http://www.w3.org/TR/WCAG10-TECHS/#tech-associate-labels [3] http://www.access-board.gov/sec508/guide/1194.22.htm#(n) [4] http://we05.com/resources/roger-hudson/association_examples.html [5] http://joeclark.org/book/sashay/serialization/Chapter08.html#p-4125 [6] http://www.wats.ca/show.php?contentid=43 [7] http://www.wats.ca/show.php?contentid=32 [8] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-tab-order ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN 55812-3009 http://www.d.umn.edu/goto/webdesign/

4 3

RELEASED Mailman 2.1.9 release candidate 1
by Barry Warsaw 06 Sep '06

06 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Mailman development team, I'm happy to announce the release of Mailman 2.1.9 release candidate 1. This is primarily a bug fix and security release, although it also contains two new languages: Arabic and Vietnamese. This version is not yet recommended for production environments, however testing and feedback is greatly encouraged. My plan is to release 2.1.9 final by 10-Sep-2006. A more detailed list of changes will be included in the final release announcement. Mailman 2.1.9rc1.tgz is available from SourceForge: https://sourceforge.net/project/showfiles.php?group_id=103 Translators: If you have any language updates you'd like to see in 2.1.9 final, please commit them now or send them to me. Enjoy, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRPnRyXEjvBPtnXfVAQKuLAP/aUjiZEelQy/oObIadsrhVl9YzP9dcbfE jK1rJuGQsB7VKHe2X/uQWuaAy95pxhNwo/j/N9qtTaSjlZvjTC74E8WboxJmCemf A+azXWgaVY/C3L+HDneqFGBVZLXkKg+4IfxmKPALcEs88jHGzOpvlnuZEVzpyaon bOYFooMqc3c= =NWI4 -----END PGP SIGNATURE-----

3 3

Traditional Chinese in Mailman 2.1.9rc1
by imacat 03 Sep '06

03 Sep '06

Dear all, I saw that you are releasing Mailman 2.1.9rc1. I hope that this issue can be seen before 2.1.9 is released. The options.html and verify.txt in Traditional Chinese are seriously outdated. They seem to be from 2.0.x. The form buttons are not right. I don't know who is in charge of the Traditional Chinese translation and localization. Could this be resolved before 2.1.9? Could anybody tell me who should I contact to? -- Best regards, imacat ^_*' <imacat(a)mail.imacat.idv.tw> PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt <<Woman's Voice>> News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

2 3