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
