Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Mar 2024 22:17:39 +0100
From:      Daniel Engberg <daniel.engberg.lists@pyret.net>
To:        Michael Gmelin <grembo@freebsd.org>
Cc:        Eugene Grosbein <eugen@grosbein.net>, Florian Smeets <flo@freebsd.org>, ports@freebsd.org
Subject:   Re: Proposed ports deprecation and removal policy
Message-ID:  <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com>
In-Reply-To: <EF5FD6F9-D6EA-45F6-8845-B0476D401EBB@freebsd.org>
References:  <7a7501f71442d27f6d8c1c0a16f247c1@mail.infomaniak.com> <EF5FD6F9-D6EA-45F6-8845-B0476D401EBB@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2024-03-14T21:49:46.000+01:00, Michael Gmelin <grembo@freebsd.org> wrote=
:
> =20
> >    On 14. Mar 2024, at 21:38, Daniel Engberg <daniel.engberg.lists@pyre=
t.net> wrote:
> > =20
> >   On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein <eugen@grosbeinnet>=
 wrote:
> >=20
> > >    12.03.2024 3:24, Daniel Engberg =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > =20
> > >  [skip]
> > > =20
> > > =20
> > >=20
> > > >      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 t=
o signal
> > > >  like if it's red it means abandonware and potentially reduced secu=
rity.
> > >  =20
> > >  Of course, we need to inform users but not enforce. Tools, not polic=
y.
> > > =20
> >   Eugene
> > =20
> >  Hi,
> > =20
> >  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 f=
or others?
> > =20
> >  Just to be clear, I'm after where do we draw the line in general.
> > =20
> >  If we look at other distros in general based on availability the decis=
ion 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?
> =20
> So your proposal is to only have ports in the tree that are safe to run o=
n unprotected public networks?
>=20
-m

I'm asking if we should purposely support it despite the efforts of keeping=
 users safe.

Best regards,
Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7fd610fa25ffb9a4348aaadf7459a689>