Date: Thu, 14 Mar 2024 23:59:14 +0100 From: Daniel Engberg <daniel.engberg.lists@pyret.net> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: Michael Gmelin <grembo@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>, Florian Smeets <flo@freebsd.org>, ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com> In-Reply-To: <20240315072753.46ffa39e1bbb2e0996099cdf@dec.sakura.ne.jp> References: <7a7501f71442d27f6d8c1c0a16f247c1@mail.infomaniak.com> <EF5FD6F9-D6EA-45F6-8845-B0476D401EBB@freebsd.org> <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com> <20240315072753.46ffa39e1bbb2e0996099cdf@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> = wrote: > On Thu, 14 Mar 2024 22:17:39 +0100 > Daniel Engberg <daniel.engberg.lists@pyret.net> wrote: >=20 >=20 > > On 2024-03-14T21:49:46.000+01:00, Michael Gmelin <grembo@freebsd.org= > wrote: > >=20 > > > =20 > > >=20 > > > > On 14. Mar 2024, at 21:38, Daniel Engberg <daniel.engberg.l= ists@pyret.net> wrote: > > > > =20 > > > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eugen@grosb= einnet> wrote: > > > > =20 > > > >=20 > > > > > 12.03.2024 3:24, Daniel Engberg =D0=BF=D0=B8=D1=88=D0= =B5=D1=82: > > > > > =20 > > > > > [skip] > > > > > =20 > > > > > =20 > > > > > =20 > > > > >=20 > > > > > > Another possible option would be to add something t= o the port's matedata that makes pkg aware and easy notiable > > > > > > like using a specific color for portname and related info= rmation to signal > > > > > > like if it's red it means abandonware and potentially red= uced security. > > > > > =20 > > > > > Of course, we need to inform users but not enforce. Tools, n= ot policy. > > > > > =20 > > > > Eugene > > > > =20 > > > > Hi, > > > > =20 > > > > Given that we seem to agree on these points in general why shou= ld such ports still be kept in the tree? We don't have such tooling availab= le and it wont likely happen anytime soon. Because it's convenient for a co= mmitter who uses these in a controlled network despite being potentially ha= rmful for others? > > > > =20 > > > > Just to be clear, I'm after where do we draw the line in genera= l. > > > > =20 > > > > If we look at other distros in general based on availability th= e 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? > > > =20 > > > So your proposal is to only have ports in the tree that are safe to= run on unprotected public networks? > > > =20 > > -m > > =20 > > I'm asking if we should purposely support it despite the efforts of ke= eping users safe. > > =20 > > 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 > --=20 Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Hi, That may very well be an option possibly with some guidelines to prevent it= turning into a loophole for being a dumping ground. Since we've moved to = git perhaps another option might be to create a separate repo (possibly via= submodules) 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 like "you're on your own" approach? Best regards, Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2cfb2038d956813eefb068a8f61e1970>