From nobody Thu Feb 29 20:36:00 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 4Tm30F61KKz5Crk3 for ; Thu, 29 Feb 2024 20:36:13 +0000 (UTC) (envelope-from SRS0=1xVm=KG=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tm30F3d0mz4jnD; Thu, 29 Feb 2024 20:36:13 +0000 (UTC) (envelope-from SRS0=1xVm=KG=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id DB8CFD7890; Thu, 29 Feb 2024 21:36:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1709238963; bh=meUZc9x935gLDDIGGbXLTtMh964lj7vQY2npKKPlE3c=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=JP5pka4P7e6h/xrRDB1TkjKeTxVxSkUy0q5DLhaE5gLu+0zGgLJHYBeNozl2CHs9q O9y9uC4wMm6tsskanHPmRWaKn8z+O1+1YQEwO14z2JSS+lBK1PpNtijJRXZZS3FGMy p+syoUgILVkmBqC19HohKqI06LWKFpqu/zzEVTaQ= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id F184FD788F; Thu, 29 Feb 2024 21:36:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1709238961; bh=meUZc9x935gLDDIGGbXLTtMh964lj7vQY2npKKPlE3c=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=zpBuxOzsQnytrHZOkx5vbw2FLg4BGEoYGMJ+ZjCCPv1KdZefoCZZLn/JmYeIRI7Xj gKqQnUaUBVl5uJuEChVV9BX4GmQ2DydTyQCjHx+Lkx5U29wKkFFEY6qfuh/PNRiPV1 wO3plsUt31h83eQLoxRJnR+RE6dhIKVJHH4NEqIQ= Message-ID: Date: Thu, 29 Feb 2024 21:36:00 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: Proposed ports deprecation and removal policy Content-Language: cs-Cestina To: Xin LI , Florian Smeets Cc: ports@freebsd.org References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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:42000, ipnet:94.124.104.0/21, country:CZ] X-Rspamd-Queue-Id: 4Tm30F3d0mz4jnD On 29/02/2024 20:26, Xin LI wrote: [...] > Could you please explain why upstream WWW would warrant a removal?  (I > think removing the WWW= entry if the website is compromised or is no > longer available is perfectly fine, but why remove the port itself?) > > - BROKEN for more than 6 months > > > I think if a port won't build on any of the official FreeBSD.org > package cluster, the port is marked BROKEN with a deprecation period of > 6 months (personally I think it's too long, 3 months should be the maximum). > > This should include ports that are IGNORED for all supported platforms > and conditionally broken with all supported defaults: they should have > correct dependency and are able to build in at least one poudriere > environment. > > - has known vulnerabilities that weren’t addressed in the ports tree > for > more than 3 months > > > I think this is somewhat too vague.  Known to whom?  Registered at > cve.mitre.org ?  In vuxml? > > Probably something like: if vuxml thinks the port is vulnerable, then > it's marked FORBIDDEN immediately with a 3 month timeout (personally I > think 2 weeks would be the maximum) by some automated script, and after > the set time of being FORBIDDEN, the port is eligible for immediate removal. Even ports of large projects, or projects on which hundreds or thousands of other ports depend, have had an unresolved security issue for much longer. For example, Python had an unpatched bug for over a month. Removing such a port after 2 weeks does more harm than good. Each user can check the pkg audit and decide for themselves if the security issue affects their environment and whether to install/retain/uninstall such a package. Removing ports for whatever reason after 2 weeks is useless. In general, I would like to see removal time frames taken not strictly from the date of discovering the technical or security problem, but with respect to quarterly branches. A lot of users use quarterly - for stability - and then are unpleasantly surprised that a port has been removed without seeing any warning. And if somebody finds a way to revert it, it will probably get reverted after the next quarter, again more harm than good. > A port can be deprecated and subsequently removed if: > > - Upstream declared the version EOL or officially stopped development. > DEPRECATED should be set as soon as the planned removal date is know. > (It is up to the maintainer if they want to remove the port immediately > after the EOL date or if they want keep the port for some time with > backported patches. Option two is *not* possible without backporting > patches, see vulnerable ports) The general suggestion is that EOL > versions should not stay in the ports tree for more than 3 months > without justification. > - The port does not adapt to infrastructure changes (i.e. USE_STAGE, > MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set > to DEPRECATED after 3 months and can be removed after 6 > > > Reasons that do not warrant removal of a port: > > - Software hasn’t seen a release in a long time > - Upstream looks inactive for a long time > > > IMHO, a lot of "friction" comes from lack of communication and not port > getting removed themselves. +1 > For example, one of my port gets marked as DEPRECATED because a > dependency was deprecated and scheduled for removal after 1 month, > without any email telling me so (the port doesn't have a lot of releases > and there isn't any release during that "parole" month), and it gets > removed after that.  So in order to know there is an ongoing deprecation > of the port, I as a port maintainer would have to either watch the > directory for any changes, or read all ports-git commit messages or at > least a filtered version of it, and that's burdensome and inefficient > use of developer time at best. > > What I would love to see happen is that, when a port gets marked as > DEPRECATED, there is an automated system that sends me notification with > something like: > > ACTION REQUESTED: X new ports you maintain is marked as DEPRECATED > > or, if it's just one port: > > ACTION REQUESTED: category/port is marked as DEPRECATED and will be > removed on 1 month > ==== > Hello, > > This is a friendly notification from FreeBSD port deprecation bot.  In > the latest scan the following ports you maintain are marked as DEPRECATED: > > Port name     | Removal date > category/port | 2024-03-30 > ... > > and that email gets sent every 7 days until the port is removed or the > issue is fixed.  Or a bug is created and assigned to the maintainer, etc. I also remember one case that annoyed me a lot - unequal treatment of ports that should have been removed due to deprecated dependencies, but some were removed "immediately" and others worked for about another year. Yes, these were Python 2.7 dependent ports, where someone was very actively removing ports that required Python 2.7 as a build dependency. Chromium wasn't removed, but Iridium was, yet it was the same build process, same dependencies (but the Iridium takes care about privacy), and throwing out hundreds of ports prematurely when Python 2.7 had to stay in the ports tree anyway was completely unnecessary and unhelpful. From my point of view, it was just a political decision and not a technical one, that shouldn't have been there. Kind regards Miroslav Lachman