Hi Michał, I created https://python-security.readthedocs.io/ website to track known Python vulnerabilities to help me checking if fixes are backported to all supported Python branches. I'm maintaing this list manually, it's far from being complete, and likely outdated.
I also created https://github.com/vstinner/check_python_vuln project which implements runtime checks for a few Python vulnerabilities. It should help users and Linux packagers to check if their Python has known vulnerabilities or not. On Thu, Feb 11, 2021 at 9:44 PM Michał Górny <mgo...@gentoo.org> wrote: > I feel that vulnerability fixes do not make it to end users fast enough. > For example, according to the current release schedules for 3.9 and 3.8, > the bugfix releases are planned two months apart. While the release is > expected to happen in the next few days, both versions are known to be > vulnerable for almost a month! We are doing our best to fix all known security vulnerabilities in all maintained Python versions (3.6, 3.7, 3.8, 3.9 and master: 5 branches). But we have no policy to define the severity of these vulnerabilities. IMO sometimes we are a little bit too conservative when marking some issues are "security" issues. For example, the https://bugs.python.org/issue41944 "CJK codecs tests call eval() on content received via HTTP" issue only impacts users running the Python test suite. https://python-security.readthedocs.io/vuln/cjk-codec-download-eval.html gives the timeline, extract: 2020-10-05 (+0 days): Reported (email sent to the PSRT list) (...) 2020-10-22 (+17 days): CVE-2020-27619 published 2020-12-07 (+63 days): Python 3.9.1 released 2020-12-21 (+77 days): Python 3.8.7 released IMO here the delay is reasonable (~2 months for 3.8 and 3.9 versions) for this kind of vulnerability. HTTP header and email header injections vulnerabilities are bad, but they can be prevented by applications. For example, good user inputs validation should prevent such vulnerability. Example of HTTP header injection timeline: https://python-security.readthedocs.io/vuln/http-header-injection-method.html Do you have a specific kind of vulnerability in mind that would require a faster release? > 2. When releases happen, security fixes are often combined with many > other changes. This causes problems for distribution maintainers who, on > one hand, would like to deploy the security fixes to production versions > ASAP, and on the other, would prefer that the new version remained in > testing for some time due to the other changes. We attempt to avoid incompatible changes in 3.x.y bug fix releases. If it happens, we can consider to revert it on a case by case basis. Usually, it is discussed before merging a change. Usually, the incompatible changes that we allow are justified... to fix security issues :-) Do you have a specific example of problematic incompatible change in mind? For me, the largest change was a Python 2.7 release which started to check TLS certificates on HTTP... It was to make Python more secure to protect users :-) > Furthermore, I think that at least for branches that are in higher level > of maintenance than security, it could make sense to actually make > security releases (e.g. 3.9.1.x) that would include only security fixes > without other changes. IMO that's too much work for everybody. developers, testers and packagers. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PBZADDEVMQNWAHMR6XZD3BAYVP3OE3HM/ Code of Conduct: http://python.org/psf/codeofconduct/
