Re: Proposed ports deprecation and removal policy

From: Charlie Li <vishwin_at_freebsd.org>
Date: Thu, 14 Mar 2024 21:41:05 UTC
Daniel Engberg 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:
>>>   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?
>>
> 
> I'm asking if we should purposely support it despite the efforts of keeping users safe.
> 
Yes. *You* may not want to support certain things that may look 
inactive, old or dependent on the same, but that does not mean others 
are not willing. Looks can be deceiving. Specifically to the security 
point, some software purposely need to otherwise appear "insecure" for 
legal and regulatory compliance in the domains they service.

None of us individually, or even as a collective, know or will know 
every last use case of everything in the ports tree. It is supremely 
important to consider valid use cases and workflows. Suggesting that 
users change their workflows to something else that is not equivalent 
because somebody wants to deprecate and remove a library that an 
otherwise active and maintained program heavily uses is not a good look.

Do not construe any of this as suggesting ports be a software museum. We 
are not in the business of coercing users to change their workflows all 
because a project's activity falls below some arbitrary threshold for 
our purposes.

We do not need another dns/djbdns debacle. That was horrendous.

-- 
Charlie Li
...nope, still don't have an exit line.