[Python-Dev] CVE tracking
Hello! Does someone systematically track the CVE vulnerability list? Ideally, Python security officers would have close collaboration with whoever manages CVE (like distribution security officers do), so that * every CVE issue would have a corresponding ticket on Python bug tracker (perhaps the process can be automated to some degree?) * that ticket would be referred to in CVE vulnerability page "References" section (see e.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315 , that does not have a corresponding Python bug tracker link) * all CVE issues would be listed in http://www.python.org/news/security/ with corresponding information about when the fix has been or will be commited and which upcoming or past release incorporates it. Some relevant links: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python http://secunia.com/advisories/product/14172/?task=advisories ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CVE tracking
Perl had a few CVE because of its rmtree implementation. Removing trees is risky business if root runs the function while other users have access to manipulate the tree. Python's shutils.rmtree seems to have many of the same issues. For instance http://bugs.debian.org/286922 shows how to get root to remove /etc/passwd. The attack should work with shutils.rmtree as well. The referenced bug is a followup to CVE-2005-0448. This just to show that there are relevant CVEs that don't have the keyword "python" attached to them. --Gisle ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 4336
Kristján Valur Jónsson wrote: Hello there. I recently created this issue: http://bugs.python.org/issue4336 3 days ago. I‘ve had no response so far. Possible reasons: no automatic assignee; core developers focused on getting 2.5.3, 2.6.1, and 3.0.0 out in the next few weeks; some people (me, at least) use Friday new issues list for issue review. > This patch solved a serious performance problem with simple xmlrpc queries for us. Any interest or thoughts? I am only slightly uncomfortable with changing the buffersize. I notice that socket._fileobject.read() Disallows small recv() calls for performance > reasons and forces buffer to at least 8k. But readline() does no such things and becomes very inefficient for the unbuffered case. Maybe it would be better just to fix socket._fileobject > to have _rbufsize be always at lest 8k You might want to add these thoughts to the issue too. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
