On Thu, 2005-02-10 at 12:32, John Dennis wrote: > At > the same time I think we should implement the stronger password > generation suggested in this open advisory against mailman. > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143 > > I believe this will need a little support in configure.in to detect and > be able to utilize the presence of /dev/urandom with an appropriate fall > back in its absence.
This is already in 2.1.6 CVS, and we do a run-time check, first for Python 2.4's os.urandom() and then for /dev/urandom. We fallback to the old scheme if neither of those can be found. > Then in the MM 3.0 time frame the entire mailman security framework > should be revisited, there are many security issues that should be > addressed. At a minimum the suggestion of supporting alternate > authentication mechanisms (e.g. pam, ldap, kerberos, etc.) should be > implemented. In my mind, this is too radical for a 2.1.x release. 3.0 is > the right time debut a more configurable and robust security framework. I agree completely, although we might be able to fit this into a 2.2 release if there is one. -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
