Re: Proposed ports deprecation and removal policy

From: Daniel Engberg <daniel.engberg.lists_at_pyret.net>
Date: Thu, 14 Mar 2024 22:59:14 UTC
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:
> 
> 
> >    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>

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