Date: Fri, 15 Mar 2024 01:30:02 +0100 From: Michael Gmelin <grembo@freebsd.org> To: Daniel Engberg <daniel.engberg.lists@pyret.net> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, Eugene Grosbein <eugen@grosbein.net>, Florian Smeets <flo@freebsd.org>, ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <9D39E988-12D0-43E6-88C1-42D82326593D@freebsd.org> In-Reply-To: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com> References: <2cfb2038d956813eefb068a8f61e1970@mail.infomaniak.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 14. Mar 2024, at 23:59, Daniel Engberg <daniel.engberg.lists@pyret.net>= wrote: > =EF=BB=BFOn 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI <junchoon@dec.saku= ra.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> w= rote: >>>>> On 14. Mar 2024, at 21:38, Daniel Engberg <daniel.engberg.lists= @pyret.net> wrote: >>>>> On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eugen@grosbeinn= et> 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 <junchoon@dec.sakura.ne.jp> >=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D39E988-12D0-43E6-88C1-42D82326593D>