Check for Python versions with security issues

[tiran]

What do you think about checking if Python itself or some of its modules are subject to security issues? @haypo has been working on a list of Python versions with security issues, https://python-security.readthedocs.io/vulnerabilities.html

[jayfk]

I like the idea @tiran. In fact, I've already started to work on this.

Calling safety with

echo "python==2.7.11" | safety check --stdin --full-report

yields something like:

╒══════════════════════════════════════════════════════════════════════════════╕
│                                                                              │
│                               /$$$$$$            /$$                         │
│                              /$$__  $$          | $$                         │
│           /$$$$$$$  /$$$$$$ | $$  \__//$$$$$$  /$$$$$$   /$$   /$$           │
│          /$$_____/ |____  $$| $$$$   /$$__  $$|_  $$_/  | $$  | $$           │
│         |  $$$$$$   /$$$$$$$| $$_/  | $$$$$$$$  | $$    | $$  | $$           │
│          \____  $$ /$$__  $$| $$    | $$_____/  | $$ /$$| $$  | $$           │
│          /$$$$$$$/|  $$$$$$$| $$    |  $$$$$$$  |  $$$$/|  $$$$$$$           │
│         |_______/  \_______/|__/     \_______/   \___/   \____  $$           │
│                                                          /$$  | $$           │
│                                                         |  $$$$$$/           │
│  by pyup.io                                              \______/            │
│                                                                              │
╞══════════════════════════════════════════════════════════════════════════════╡
│ REPORT                                                                       │
╞════════════════════════════════╤═══════════════╤═════════════════════════════╡
│ package                        │ installed     │ affected                    │
╞════════════════════════════════╧═══════════════╧═════════════════════════════╡
│ python                         │ 2.7.11        │ <2.7.12                     │
╞══════════════════════════════════════════════════════════════════════════════╡
│ Integer overflow in the get_data function in zipimport.c in CPython (aka Pyt │
│ hon) before 2.7.12, 3.x before 3.4.5, and 3.5.x before 3.5.2 allows remote a │
│ ttackers to have unspecified impact via a negative data size value, which tr │
│ iggers a heap-based buffer overflow.                                         │
╞══════════════════════════════════════════════════════════════════════════════╡
│ python                         │ 2.7.11        │ <2.7.12                     │
╞══════════════════════════════════════════════════════════════════════════════╡
│ The smtplib library in CPython (aka Python) before 2.7.12, 3.x before 3.4.5, │
│  and 3.5.x before 3.5.2 does not return an error when StartTLS fails, which  │
│ might allow man-in-the-middle attackers to bypass the TLS protections by lev │
│ eraging a network position between the client and the registry to block the  │
│ StartTLS command, aka a "StartTLS stripping attack."                         │
╞══════════════════════════════════════════════════════════════════════════════╡
│ python                         │ 2.7.11        │ >=2.6,<3.3                  │
╞══════════════════════════════════════════════════════════════════════════════╡
│ Python 2.6 through 3.2 creates ~/.pypirc with world-readable permissions bef │
│ ore changing them after data has been written, which introduces a race condi │
│ tion that allows local users to obtain a username and password by reading th │
│ is file.                                                                     │
╘══════════════════════════════════════════════════════════════════════════════╛

Using @haypo's would be a much better option, though.

From what it looks like (vulnerabilities.yaml)[https://github.com/haypo/python-security/blob/master/vulnerabilities.yaml] seems to contain all the info we need, except for the specifiers.

---

Ideally, I'd like to introduce a new subcommand that can be called with safety check python.

What do you think?

---

Given the fact that safety is supposed to support windows, we might run into problems adding pyyaml as a dependency. Might want to take a look at poyo. This should work, @hackebrot?

[vstinner]

From what it looks like (vulnerabilities.yaml)[https://github.com/haypo/python-security/blob/master/vulnerabilities.yaml] seems to contain all the info we need, except for the specifiers.

What are specifiers?

Given the fact that safety is supposed to support windows, we might run into problems adding pyyaml as a dependency. Might want to take a look at poyo. This should work, @hackebrot?

My Git repository contains raw data and tools to "compile" data. You are free to generate your own output which doesn't require any dependency. For example, my output is a Sphinx documentation compiled to HTML which doesn't need PyYAML to be read :-D

[jayfk]

I was referring to https://github.com/pypa/packaging/blob/master/docs/specifiers.rst

Basically translating the commits to vulnerable releases, something like:

- name: "Issue #26556: Expat 2.1.1"
  fixed-in:
    - d244a8f7cb0ec6979ec9fc7acd39e95f5339ad0e # 2.7.12
    - 196d7db3956f4c0b03e87b570771b3460a61bab5 # 3.4.5
  description: ...
  vulnerable:
    - >=3.4,<3.4.5
    - >=2.7,<2.7.12

This allows to do find vulnerable releases using the packaging library:

>>> from packaging.specifiers import SpecifierSet
>>> vuln = SpecifierSet(">=3.4,<3.4.5")
>>> vuln.contains("3.4.2")
True

[hackebrot]

@jayfk, while poyo works just fine for cookiecutter configs, I would not want to use it for something else unless you really need to, say if PyYAML breaks a number of your users (which was the case for us).

poyo is very limited in what it can do. At this point I don't want to invest the time to add more to it that strictly necessary for cookiecutter. 🤔