Date: Mon, 11 Mar 2024 21:24:34 +0100 From: Daniel Engberg <daniel.engberg.lists@pyret.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: Florian Smeets <flo@FreeBSD.org>, ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <9646fd5d0666c8e57795ea1b370b6af1@mail.infomaniak.com> In-Reply-To: <64c7435c-2d69-1f62-ba7c-30812860a457@grosbein.net> References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <1c5b7818-842f-f7b8-9d4e-5bf681cad20e@grosbein.net> <c5e3e5d2d058d90777828b88a0f1506e@mail.infomaniak.com> <64c7435c-2d69-1f62-ba7c-30812860a457@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2024-03-11T18:22:57.000+01:00, Eugene Grosbein <eugen@grosbein.net> wrot= e: > 11.03.2024 4:49, Daniel Engberg wrote: >=20 >=20 > > =20 > > > =20 > > > > Ports can be removed immediately if one of the following condit= ions is met: > > > > =20 > > > > - Upstream distfile is no longer available from the original sour= ce/mirror > > > > (Our and other distcaches e.g. Debian, Gentoo, etc do not count a= s "available") > > > > - Upstream WWW is unavailable: deprecate, remove after 3 months > > > [skip] > > >=20 > > > > A port can be deprecated and subsequently removed if: > > > > - Upstream declared the version EOL or officially stopped develop= ment. > > > > DEPRECATED should be set as soon as the planned removal date is k= now. > > > =20 > > > Objection to quoted reasons. A software not developed anymore but st= ill works fine > > > after years is best software ever. Do not touch it, please. > > >=20 > > > Some examples: > > >=20 > > > 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 FreeB= SD kernel > > > net-im/pidgin-manualsize abadoned by initial author years ago > > > databases/oracle8-client the only known library to link native FreeB= SD code with for OracleDB connection > > >=20 > > > Do not "fix" what ain't broken. > > >=20 > > Eugene > > =20 > > I'm going to assume that there will be a PR or something regarding mai= ntained ports either way. > =20 > I maintain most of listed ports. >=20 >=20 > > As far as the "Do not "fix" what ain't broken" argument goes one maj= or concern is how do you know=20 > > especially regarding to Internet facing services? > =20 > Not every port deals with public Internet and services therein. >=20 >=20 > > 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. > =20 > And not need to, practice shows. >=20 >=20 > > There likely aren't many eyes on the software by now (I guess for bo= th good and bad reasons) > > but it might also very well bite you or users in the end. > =20 > Until then, it works and let it be. >=20 >=20 > > That being said, all software contains bugs > =20 > True. The question is, do any of bugs affect particular setup? If not, le= t it be. >=20 >=20 > > 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. > =20 > There are private networks not exposed to untrusted users or hosts not af= fected by any security concerns, > including one-user-only. No need to break their setups. >=20 >=20 > > Quagga is in a similar position, pfsense seems to point users to frr= and there's also other software such as bird/bird2. > =20 > frr development is Linux-centric and its OSPF implementation has some pro= blems under FreeBSD ignored by developers, > it cannot be a replacement (can't tell for bird/bird2). Quagga ospfd/bgpd= work fine, let it be. >=20 >=20 > > According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support e= nded 20 years ago, > > it's also marked as i386 only so its days are counted. > =20 > This is userland library and we have no plans to eliminate userland i386 = support yet. > No alternatives, also. >=20 >=20 > > Nothing is stopping people to use an overlay but not everything need= s to be in or rather stay the "public" repo forever. > =20 > Not forever. While it works fine. >=20 Eugene Since your average user is connected to the Internet to utilize ports and/o= r 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 r= eporting, upstream etc) and ports security team exists for this very reason= , if upstream reporting facilities aren't available then there's a higher r= isk of security reports and patches slipping by. This is one of the reasons= why many repositories remove abandonware, outdated versions etc. Not sayin= g it's valid argument but given our efforts try to keep users safe in gener= al that approach seems reasonable? Taking it to the extreme I'm not sure pu= tting a banner saying something like "X probably works fine on a private ne= twork with trusted hosts" is going to send a positive and reassuring messag= e or tell people when shit hits the fan "It's abandonware, you're on your o= wn and you should've known better" . Another possible option would be to add something to the port's matedata th= at makes pkg aware and easy notiable like using a specific color for portna= me and related information to signal like if it's red it means abandonware = and potentially reduced security. Best regards, Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9646fd5d0666c8e57795ea1b370b6af1>