Re: Proposed ports deprecation and removal policy

On 2024-03-15T08:25:10.000+01:00, Eugene Grosbein <eugen@grosbein.net> wrote:
>  15.03.2024 3:37, Daniel Engberg wrote:
> 
> >    On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eugen@grosbein.net> 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?
>  
> A port should be kept in the tree until it works and has no known security problems, not imaginable.
> 
> 
> >    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?
>  
> "Potentially harmful" is not valid reason to remove a port. Look at vulnerability history of any modern web browser.
> We know they are full of security holes. All of them. And will be despite of being supported by developers, it does not matter in fact.
> Old software is often much more simple and secure despite of lack of support.
> 
> Do not remove ports just due to theorizing.
> 
Eugene

A key difference is though that browsers such as Firefox or Chromium are maintained upstream including reporting etc. That's a very different matter compared to using even a deprecated version upstream of lets say Apache (1.3.x for example). I agree it's a difficult topic and I think for the sake user expenience/friendliness (if we are to take that into accout) apart from the rest of potential issues most will not scour the internet to determine this.

Best regards,
Daniel