On 2024-03-15T08:25:10.000+01:00, Eugene Grosbein <eu...@grosbein.net> wrote: > 15.03.2024 3:37, Daniel Engberg wrote: > > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eu...@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.3x 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
