On 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote: > On Thu, 14 Mar 2024 22:17:39 +0100 > Daniel Engberg <daniel.engberg.li...@pyret.net> wrote: > > > > On 2024-03-14T21:49:46.000+01:00, Michael Gmelin <gre...@freebsd.org> > > wrote: > > > > > > > > > > > > On 14. Mar 2024, at 21:38, Daniel Engberg > > > > <daniel.engberg.li...@pyret.net> wrote: > > > > > > > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein > > > > <eugen@grosbeinnet> 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 <junch...@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
