Re: Proposed ports deprecation and removal policy

On 2024-03-11T18:22:57.000+01:00, Eugene Grosbein <eugen@grosbein.net> wrote:
>  11.03.2024 4:49, Daniel Engberg wrote:
> 
> 
> >  
> > >  
> > > >     Ports can be removed immediately if one of the following conditions is met:
> > > >   
> > > >   - Upstream distfile is no longer available from the original source/mirror
> > > >   (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "available")
> > > >   - Upstream WWW is unavailable: deprecate, remove after 3 months
> > >   [skip]
> > > 
> > > >       A port can be deprecated and subsequently removed if:
> > > >   - Upstream declared the version EOL or officially stopped development.
> > > >   DEPRECATED should be set as soon as the planned removal date is know.
> > >    
> > >  Objection to quoted reasons. A software not developed anymore but still works fine
> > >  after years is best software ever. Do not touch it, please.
> > > 
> > >  Some examples:
> > > 
> > >  mail/qpopper   abadoned by Qualcomm years ago
> > >  russian/d1489   created by ache@ who passed away years ago
> > >  net/quagga   abadonware but still best OSPF implementation for FreeBSD kernel
> > >  net-im/pidgin-manualsize abadoned by initial author years ago
> > >  databases/oracle8-client the only known library to link native FreeBSD code with for OracleDB connection
> > > 
> > >  Do not "fix" what ain't broken.
> > > 
> >   Eugene
> >  
> >  I'm going to assume that there will be a PR or something regarding maintained ports either way.
>  
> I maintain most of listed ports.
> 
> 
> >    As far as the "Do not "fix" what ain't broken" argument goes one major concern is how do you know 
> >  especially regarding to Internet facing services?
>  
> Not every port deals with public Internet and services therein.
> 
> 
> >    Qpopper (for example) has been dropped by pretty much every distro
> >  https://repology.org/project/qpopper/versions and upstream is dead so there's no hub for communication.
>  
> And not need to, practice shows.
> 
> 
> >    There likely aren't many eyes on the software by now (I guess for both good and bad reasons)
> >  but it might also very well bite you or users in the end.
>  
> Until then, it works and let it be.
> 
> 
> >    That being said, all software contains bugs
>  
> True. The question is, do any of bugs affect particular setup? If not, let it be.
> 
> 
> >    including active projects so it's not like it's a clean cut in terms of security concerns (wordpress)
> >  but you'll likely see issues being adressed and reported when software is more widely available.
> >  If upstream is dead it's very likely that security reports ends up in some package repo,
> >  random hosted fork or such and never finds it way outside of it.
>  
> There are private networks not exposed to untrusted users or hosts not affected by any security concerns,
> including one-user-only. No need to break their setups.
> 
> 
> >    Quagga is in a similar position, pfsense seems to point users to frr and there's also other software such as bird/bird2.
>  
> frr development is Linux-centric and its OSPF implementation has some problems under FreeBSD ignored by developers,
> it cannot be a replacement (can't tell for bird/bird2). Quagga ospfd/bgpd work fine, let it be.
> 
> 
> >    According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support ended 20 years ago,
> >  it's also marked as i386 only so its days are counted.
>  
> This is userland library and we have no plans to eliminate userland i386 support yet.
> No alternatives, also.
> 
> 
> >    Nothing is stopping people to use an overlay but not everything needs to be in or rather stay the "public" repo forever.
>  
> Not forever. While it works fine.
> 
Eugene

Since your average user is connected to the Internet to utilize ports and/or packages I think a sound assumption would be that Internet is going to be an attack vector. While we can't safeguard for every possible scenario we do have the ability however to "protect" users to some extent. VuXML (CVE reporting, upstream etc) and ports security team exists for this very reason, if upstream reporting facilities aren't available then there's a higher risk of security reports and patches slipping by. This is one of the reasons why many repositories remove abandonware, outdated versions etc. Not saying it's valid argument but given our efforts try to keep users safe in general that approach seems reasonable? Taking it to the extreme I'm not sure putting a banner saying something like "X probably works fine on a private network with trusted hosts" is going to send a positive and reassuring message or tell people when shit hits the fan "It's abandonware, you're on your own and you should've known better" .

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.

Best regards,
Daniel