Date: Sat, 20 Nov 2021 02:52:40 UTC
Maxim Sobolev <firstname.lastname@example.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.