From nobody Thu Mar 14 22:27:53 2024 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 4Twhps3FQ9z5Djfn for ; Thu, 14 Mar 2024 22:28:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Twhpr4gDrz527F; Thu, 14 Mar 2024 22:28:04 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 42EMRshB076363; Fri, 15 Mar 2024 07:27:54 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 15 Mar 2024 07:27:53 +0900 From: Tomoaki AOKI To: Daniel Engberg Cc: Michael Gmelin , Eugene Grosbein , Florian Smeets , ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-Id: <20240315072753.46ffa39e1bbb2e0996099cdf@dec.sakura.ne.jp> In-Reply-To: <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com> References: <7a7501f71442d27f6d8c1c0a16f247c1@mail.infomaniak.com> <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4Twhpr4gDrz527F On Thu, 14 Mar 2024 22:17:39 +0100 Daniel Engberg wrote: > On 2024-03-14T21:49:46.000+01:00, Michael Gmelin wrote: > > > > > On 14. Mar 2024, at 21:38, Daniel Engberg wrote: > > > > > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein wrote: > > > > > > > 12.03.2024 3:24, Daniel Engberg пишет: > > > > > > > > [skip] > > > > > > > > > > > > > > > > > Another possible option would be to add something to the port's matedata that makes pkg aware and easy notiable > > > > > like using a specific color for portname and related information to signal > > > > > like if it's red it means abandonware and potentially reduced security. > > > > > > > > Of course, we need to inform users but not enforce. Tools, not policy. > > > > > > > Eugene > > > > > > Hi, > > > > > > Given that we seem to agree on these points in general why should such ports still be kept in the tree? We don't have such tooling available and it wont likely happen anytime soon. Because it's convenient for a committer who uses these in a controlled network despite being potentially harmful for others? > > > > > > Just to be clear, I'm after where do we draw the line in general. > > > > > > If we look at other distros in general based on availability the decision seems to favour overall user security than "convenience". Given that we have security policies etc in place I'd say that we in general are leaning towards user security? > > > > So your proposal is to only have ports in the tree that are safe to run on unprotected public networks? > > > -m > > I'm asking if we should purposely support it despite the efforts of keeping users safe. > > Best regards, > Daniel How about setting NO_PACKAGE [1] to force admins to build from ports by themselves for such risky but too usful to delete ports? You may also want to introduce something like LICENSE framework to force interaction on build/install, but without something like LICENSES_ACCEPTED+= variable to bypass it. [1] https://docs.freebsd.org/en/books/porters-handbook/special/#porting-restrictions -- Tomoaki AOKI