Re: Proposed ports deprecation and removal policy
- In reply to: Daniel Engberg : "Re: Proposed ports deprecation and removal policy"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.