Re: Proposed ports deprecation and removal policy

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 <http://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