> On 14. Mar 2024, at 23:59, Daniel Engberg <daniel.engberg.li...@pyret.net>
> wrote:
> On 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI <junch...@dec.sakura.ne.jp>
> wrote:
>> On Thu, 14 Mar 2024 22:17:39 +0100
>> Daniel Engberg <daniel.engberg.li...@pyret.net> wrote:
>>
>>
>>> On 2024-03-14T21:49:46.000+01:00, Michael Gmelin <gre...@freebsd.org>
>>> wrote:
>>>>> On 14. Mar 2024, at 21:38, Daniel Engberg
>>>>> <daniel.engberg.li...@pyret.net> wrote:
>>>>> On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eugen@grosbeinnet>
>>>>> 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? 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?
>>> -m
>>> I'm asking if we should purposely support it despite the efforts of keeping
>>> users safe.
>>> Best regards,
>>> Daniel
>>
>> How about setting NO_PACKAGE [1] to force admins to build from ports
>> by themselves for such risky but too usful to delete ports?
>>
>> You may also want to introduce something like LICENSE framework to
>> force interaction on build/install, but without something like
>> LICENSES_ACCEPTED+= variable to bypass it.
>>
>>
>> [1]
>> https://docs.freebsd.org/en/books/porters-handbook/special/#porting-restrictions
>>
>>
>> --
> Tomoaki AOKI <junch...@dec.sakura.ne.jp>
>
> Hi,
>
> That may very well be an option possibly with some guidelines to prevent it
> turning into a loophole for being a dumping ground. Since we've moved to git
> perhaps another option might be to create a separate repo (possibly via
> submodules) with less restricive polices and have that as an "add-on" for the
> official tree without the ports team's and committers's involvement, a bit
> like "you're on your own" approach?
Managing these ports outside of the tree won’t do maintainers and users any
favor and make managing local trees, quarterly branches etc. a nightmare. It
would literally create a pile of broken stuff that rots and gets worse over
time.
A pragmatic approach would be to add ports that aren’t maintained upstream
anymore to VuXML (or a similar mechanism used by “pkg audit”), so users would
get warned when installing/about installed packages that *could* be dangerous
due to being unmaintained (but these entries should be opt-out, in case users
decide not to see these kinds of warnings).
-m
