From nobody Fri Mar 15 00:30:02 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 4TwlWg0Gxwz5DvMl for ; Fri, 15 Mar 2024 00:30:07 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TwlWf2yvQz41fT; Fri, 15 Mar 2024 00:30:06 +0000 (UTC) (envelope-from grembo@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 552d870a; Fri, 15 Mar 2024 00:30:03 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 1bcfd8e8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 15 Mar 2024 00:30:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (1.0) Subject: Re: Proposed ports deprecation and removal policy From: Michael Gmelin In-Reply-To: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com> Cc: Tomoaki AOKI , Eugene Grosbein , Florian Smeets , ports@freebsd.org Date: Fri, 15 Mar 2024 01:30:02 +0100 Message-Id: <9D39E988-12D0-43E6-88C1-42D82326593D@freebsd.org> References: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com> To: Daniel Engberg X-Mailer: iPhone Mail (20H320) 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:24940, ipnet:213.239.192.0/18, country:DE] X-Rspamd-Queue-Id: 4TwlWf2yvQz41fT > On 14. Mar 2024, at 23:59, Daniel Engberg = wrote: > =EF=BB=BFOn 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI wrote: >> On Thu, 14 Mar 2024 22:17:39 +0100 >> Daniel Engberg wrote: >>=20 >>=20 >>> On 2024-03-14T21:49:46.000+01:00, Michael Gmelin w= rote: >>>>> 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 =D0=BF=D0=B8=D1=88=D0=B5=D1=82= : >>>>>> [skip] >>>>>>> Another possible option would be to add something to the p= ort's matedata that makes pkg aware and easy notiable >>>>>>> like using a specific color for portname and related informatio= n to signal >>>>>>> like if it's red it means abandonware and potentially reduced s= ecurity. >>>>>> Of course, we need to inform users but not enforce. Tools, not po= licy. >>>>> Eugene >>>>> Hi, >>>>> Given that we seem to agree on these points in general why should s= uch ports still be kept in the tree? We don't have such tooling available an= d it wont likely happen anytime soon. Because it's convenient for a committe= r who uses these in a controlled network despite being potentially harmful f= or 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 de= cision seems to favour overall user security than "convenience". Given that w= e 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 ru= n on unprotected public networks? >>> -m >>> I'm asking if we should purposely support it despite the efforts of keep= ing users safe. >>> Best regards, >>> Daniel >>=20 >> How about setting NO_PACKAGE [1] to force admins to build from ports >> by themselves for such risky but too usful to delete ports? >>=20 >> You may also want to introduce something like LICENSE framework to >> force interaction on build/install, but without something like >> LICENSES_ACCEPTED+=3D variable to bypass it. >>=20 >>=20 >> [1] >> https://docs.freebsd.org/en/books/porters-handbook/special/#porting-restr= ictions >>=20 >>=20 >> -- > Tomoaki AOKI >=20 > Hi, >=20 > That may very well be an option possibly with some guidelines to prevent i= t turning into a loophole for being a dumping ground. Since we've moved to g= it perhaps another option might be to create a separate repo (possibly via s= ubmodules) with less restricive polices and have that as an "add-on" for the= official tree without the ports team's and committers's involvement, a bit l= ike "you're on your own" approach? Managing these ports outside of the tree won=E2=80=99t do maintainers and us= ers any favor and make managing local trees, quarterly branches etc. a night= mare. It would literally create a pile of broken stuff that rots and gets wo= rse over time. A pragmatic approach would be to add ports that aren=E2=80=99t maintained up= stream anymore to VuXML (or a similar mechanism used by =E2=80=9Cpkg audit=E2= =80=9D), so users would get warned when installing/about installed packages t= hat *could* be dangerous due to being unmaintained (but these entries should= be opt-out, in case users decide not to see these kinds of warnings). -m