On Tue, 2021-02-16 at 00:53 +0100, Victor Stinner wrote:
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.
Thank you.
On Thu, Feb 11, 2021 at 9:44 PM Michał Górny <mgorny@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.
I generally try to avoid making assumptions about severity of security bugs, and treat all of them the same.
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.
I have ignored this one as well, since we are running the test suite with network access disabled. I can't complain for this one but I don't know whether it doesn't impact other people's workflows. Please correct me if I'm missing something but if a distro packager uses a workflow like 'build, run tests, install' (this is what we do), I believe that this vulnerability could be used to inject malware into Python packages distributed with a lot of distributions.
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.htm...
Do you have a specific kind of vulnerability in mind that would require a faster release?
As I said above, I try not to make assumptions about severity. However, I personally wouldn't rely on people having their scripts fully protected or actually doing anything to workaround vulnerabilities in CPython. If we have a fix handy, it is our responsibility to deploy it.
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 :-)
I didn't mean intended incompatibilities. I meant the possibility of new bugs. I can't say I recall such a problem with CPython but that doesn't mean that there weren't sneaky issues in the past. We have a testing process in place to give braver users a chance to discover such problems.
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.
I do realize that's extra work for people responsible for making the release but packagers are doing the work already (or should be doing it). -- Best regards, Michał Górny