From nobody Sat Nov 20 02:52:40 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36068188A5C5 for ; Sat, 20 Nov 2021 02:52:47 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hwykl12HQz51BQ; Sat, 20 Nov 2021 02:52:47 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637376767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HEXcMMY3zqG9je3xjP9NaZqiw8BwTytgJNe1veBZBEE=; b=LmLomnhUev66qDgXkTMv30dXOYi1DS0FH1tnssF5hyohZN/Gk7HV6O/3gTkS/8C4FubNYr OSGACfh7e5lvmDVao5XOoa9AxGQoTCUGI1NvkkRzFsjwUZRJpb2dwRHoUNsWUXIdwtvIx+ gokvhnmX7+Trr3veqROvO7uXlqkgG6F+IUcXjD92MHyW0KaNO1y40OMbQJZDP8upVCqSfe BT9H4DvDVzeCNnQFy9uLPjuOi1ti8aH8IGVOgS2pP6ETuoZ2PeOy/wrYUiXZlUJnp5XTWU OAzvlotQILgLefj6BXTezEiaxjF78gRwuGcXeVNfOTqyHRN5t/f0l+GrdplHnw== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 145F5122A2; Sat, 20 Nov 2021 02:52:47 +0000 (UTC) From: Jan Beich To: Maxim Sobolev Cc: ports@freebsd.org Subject: Re: Bringing back lang/python27 with few modules? References: <09b3a479-5aca-7524-bcee-f03754fefd7c@bluerosetech.com> Date: Sat, 20 Nov 2021 03:52:40 +0100 In-Reply-To: (Maxim Sobolev's message of "Fri, 19 Nov 2021 17:07:28 -0800") Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637376767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HEXcMMY3zqG9je3xjP9NaZqiw8BwTytgJNe1veBZBEE=; b=aNCcXpNCP93aqC3HY1KX1pub8jj2VzgWCJDfXCbFzOuYlNVsX35F6CqkvcjLFoh67gMYfD ZFSSw3SPTxc//WLE497jMaOOHc+eTe3gWrrsH/U1dsc0Vo6qP9viZPI2cANVfzJChFiaia yFXFDI/KKRzAn8CSdkAmocfMvMKrZ90y4/HmC4ASVJF0fXzElCPpyKsXBzZKxBSLN92WTm KAnH2KaBPaLCDCTSrlBPMWJuXSkGKX1sL4yswIOdiNXxVkigQVMu4h7AvngwryqOYS+Bqy EYYc3M8nx6rviK38ePtFtFd9V99YjhSuDA8hGrxmbZWswPZwn1F8Q4sHf4uxLA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637376767; a=rsa-sha256; cv=none; b=KDR4kPq/ZuRwk/xMTziUhBka5n4v4u8wkS6Yr8jduWO1SuxN3hvBfzWRG/bLgKNkZzELoz uYj6uqh1FsgyLuC8fNGAX31utzBsTloZjrjMgqiCqKhxwtYwWECOFW9jYMlFjJFF03t6Ay JbZFTHftdG0I4wYx/Rp+KGHtNNBiOyk3PGyYhS3hGiLNlTgxQ0EIZnO3qwYK7D1xTauwYd wzgHXCQ31kFStbeItnfDM4rcuCvhoTuiA3/+Py1YweLwEL35xz/zzvi3H3HHoR9lbnSKb3 WjWcp6UvWjMQjzGikH5bdDqeuVatcwxeR+PDUxTHXKysyhuPrirUnWbc5USOng== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Maxim Sobolev 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.