Re: Proposed ports deprecation and removal policy
Date: Thu, 14 Mar 2024 22:27:53 UTC
On Thu, 14 Mar 2024 22:17:39 +0100 Daniel Engberg <daniel.engberg.lists@pyret.net> wrote: > On 2024-03-14T21:49:46.000+01:00, Michael Gmelin <grembo@freebsd.org> wrote: > > > > > 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@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 <junchoon@dec.sakura.ne.jp>