From nobody Thu Mar 14 21:17:39 2024 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TwgFh6hwfz5DbSn for ; Thu, 14 Mar 2024 21:17:44 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from smtp-42a9.mail.infomaniak.ch (smtp-42a9.mail.infomaniak.ch [IPv6:2001:1600:7:10::42a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "relay.mail.infomaniak.ch", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TwgFf6sMyz4lQZ for ; Thu, 14 Mar 2024 21:17:42 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Authentication-Results: mx1.freebsd.org; none Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4TwgFb6yJszXrd; Thu, 14 Mar 2024 22:17:39 +0100 (CET) Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4TwgFb4K8vzHfm; Thu, 14 Mar 2024 22:17:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pyret.net; s=20231006; t=1710451059; bh=u7ONhz7AxToNECTBX83Swx4+ohyNKsJE2QsW71vCwRE=; h=Date:Subject:From:Reply-To:To:Cc:References:In-Reply-To:From; b=TEYBr/hB0U7B3xX7ci9JuPEiIDRMS3vCJjz9wnXLl7w5cxvJnj1jmhsLit6Sqc5z5 Ai+95ScQf0xLY3FDppthRQ/p+29xW/9RTcDxIIU+RPABZbZBcQ4b2fEn9AFq9JW41n L3QFNmF1ecm3MbWDEkZYRUi4E176TXlqYrNugIFetXv3y20kTsW6zx1chR85fV7F6z 9hyKGxfdgW7Fq4CKaTPQESrePuhOxsNaw+6VuXoFpajYYD1jOd464B7ThyYDRw90Wj 1s7FTwlJ1+NnUyZ8OrUGeyBSqNjtInDS0jgtSCgqscTZ+izjom7XSLUgYRkWoU1qzj zMDTlNVTo4J4Q== Message-ID: <7fd610fa25ffb9a4348aaadf7459a689@mail.infomaniak.com> Date: Thu, 14 Mar 2024 22:17:39 +0100 Subject: Re: Proposed ports deprecation and removal policy From: Daniel Engberg Reply-To: Daniel Engberg To: Michael Gmelin Cc: Eugene Grosbein , Florian Smeets , ports@freebsd.org List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-WS-User-Origin: eyJpdiI6IjdaRGJkRzh3RWxUYzhBOE9OdGJEVVE9PSIsInZhbHVlIjoiUmZqK0NxMVphT2w1UEo1K21mQXNQZz09IiwibWFjIjoiYWQyOTU2NzdiNzViODRiNGEyZjIyZjJlODk0YWZmODczNDY0MGFiYjY3OGIxMTNjOTZjYzJlYTNmZDA4ZWViZCIsInRhZyI6IiJ9 X-WS-User-Mbox: eyJpdiI6Im5kUktMb3FCdkYwdlEwcldmdXVsY3c9PSIsInZhbHVlIjoiMm9ZWGcvdG5QTGpFV0IyYlpwSEhqQT09IiwibWFjIjoiMjgyYmYzZjVjMGFhOTFmYzZhMjRmYzlmZWQ2ZWM3NDI0NWMxODIyMjRkNTcyYzQ1ZjhkNzg5MTQzYjNlMDRiOCIsInRhZyI6IiJ9 X-WS-Location: eJxzKUpMKykGAAfpAmU- X-Mailer: Infomaniak Workspace (1.3.654) References: <7a7501f71442d27f6d8c1c0a16f247c1@mail.infomaniak.com> In-Reply-To: X-Infomaniak-Routing: alpha X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29222, ipnet:2001:1600::/32, country:CH] X-Rspamd-Queue-Id: 4TwgFf6sMyz4lQZ On 2024-03-14T21:49:46.000+01:00, Michael Gmelin wrote= : > =20 > > On 14. Mar 2024, at 21:38, Daniel Engberg wrote: > > =20 > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein = 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