Re: Bringing back lang/python27 with few modules?

Maxim Sobolev <sobomax@freebsd.org> writes:

> Well with regards to a language port, "vulnerability" has somewhat dubious
> applicability. For sure there are many ways to write an insecure C program
> allowed by the language itself. Shall we consider all C compilers
> inheretedly bad based on just that?

CPython provides not just the compiler but also runtime. As C originally
came from Unix all compatible (via POSIX) systems have something like libc
shipped by OS vendor instead of language implementation. FreeBSD Project
doesn't support EOL versions of FreeBSD, so in ports/ the support for
vulnerable libc versions evaporates very quickly.

Vulnerabilities in language runtimes are far more common than in codegen e.g.,
https://nvd.nist.gov/vuln/search/results?query=cpe:2.3:a:golang:go:1.15.0
https://nvd.nist.gov/vuln/search/results?query=cpe:2.3:a:rust-lang:rust:1.48.0
https://nvd.nist.gov/vuln/search/results?query=cpe:2.3:a:python:python:2.7.0

lang/pypy can probably be resurrected by using prebuilt binary for bootstrap
instead of lang/python27. Kinda similar to lang/rust, lang/ghc, lang/sbcl.
However, I'm *not* interested myself, USES=python doesn't support lang/pypy,
blindly replacing CPython with PyPy rarely works and modules still supporting
Python 2.* maybe unmaintained upstream thus potentially vulnerable.