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 <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. 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.html > > 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 _______________________________________________ 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/IH7QSDNS6GGLGQNITB5RMNORZCMOMYIF/ Code of Conduct: http://python.org/psf/codeofconduct/
