Date: Sat, 6 Dec 2025 13:53:19 +0100 From: Robert Clausecker <fuz@fuz.su> To: Mathieu Arnold <mat@freebsd.org> Cc: Adam Weinberger <adamw@freebsd.org>, Michael Gmelin <grembo@freebsd.org>, ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: f45b1d07f50b - main - many: Unsupported Go dep; deprecate and schedule for removal Message-ID: <aTQnP6fp8Mdnt1lD@fuz.su> In-Reply-To: <anueicii6nrst5ifn3mq4n22pc7o4geszhjvirxfmxfsu4x675@p4hl5n3mxpt5> References: <6932e88b.2dbf8.7aad26de@gitrepo.freebsd.org> <aTL4-HmeB5utBsO1@fuz.su> <20251205165440.4359b77f.grembo@freebsd.org> <CAP7rwcgh1qbY29Yn8TqxXyQjsM1tBwakJjm=oosq7xHnG64ETw@mail.gmail.com> <aTMDRtvwzBzXi2er@fuz.su> <anueicii6nrst5ifn3mq4n22pc7o4geszhjvirxfmxfsu4x675@p4hl5n3mxpt5>
index | next in thread | previous in thread | raw e-mail
Hello Mathieu, Am Sat, Dec 06, 2025 at 11:48:08AM +0100 schrieb Mathieu Arnold: > On Fri, Dec 05, 2025 at 05:07:34PM +0100, Robert Clausecker wrote: > > Hi Adam, > > > > Please follow Porter's Handbook which gives 1 month for security issues > > or 2 months for build issues. Note that a CVE in the toolchain does not > > mean that applications built with it are affected, that's only the case > > if the application uses the affected component, so it's usually not a > > security issue. > > > > IMHO it should be 3 months though. > > While the Porter's Handbook provides general timelines, it is not always > possible or desirable to follow those rules strictly in every situation. > When dealing with toolchain deprecations or unmaintained software, > waiting the full duration can lead to larger maintenance burdens or > security exposure across the ports tree. > > In such cases, portmgr approval allows us to deviate from the standard > timelines when it is in the best interest of the project. This > flexibility is intentional and ensures that we can address issues > promptly and responsibly. > > As I wrote earlier, if a port is removed, and is still of interest, it > remains easy to retrieve it from the Git history should someone wish to > revive or maintain it later. While I do understand that it is necessary to check affected ports, the way it has been done leaves a sour taste with me. There are three items to consider here: - in almost all cases, people pin a specific Go version because at the time they added the port, the default Go version was too old to build the port. This can be observed during "make makesum" when Go will say "downloading Go toolchain ...", meaning that Go cannot build the port and must download a newer toolchain to do so. Therefore, the actual intent is to say "at least this version of Go is needed" instead of "exactly this version of Go is needed", but go.mk has no support for the former. As such, for almost all, probably all of these ports, there isn't anything wrong with them, and they should build just fine just by removing the Go toolchain pin. This could have been done with a simple exp-run, and long term, by amending go.mk to support version pinning with ranges (i.e. USES=go:1.25+ as we have it for Python). In any case, deprecation seems wildly inappropriate. We should also change go.mk to set GOTOOLCHAIN=local, so that it does not try to download a newer toolchain in any case, but that's another debate. - DEPRECATED is a notice to users, not developers. It tells the user "this port will go away, migrate to another one." However, here the notice is used to inform developers that they need to take action. This is not what DEPRECATED is meant for and I've had users who sent me emails being confused about whiplashes about random ports being deprecated and then suddenly being fine again a few days later, casting doubt about the overall reliability of ports. We should not use DEPRECATED to force maintainers into action as this diminishes the value of the tag for users, who are no longer able to trust a port being deprecated as a sure sign that they need to take action. DEPRECATED should only be used for when it's clear that there is no fixing the port and that it's very likely to go away. - given that the holidays are drawing near, the timeline is very tight. I have a full schedule until the new year and am not very pleased at being told to "take action right now or your ports will be removed" with no prior notice, especially for such a silly reason with a trivial fix. Yes, there are open CVEs in Go 1.23, but they all affect specific library routines and none of them are particularly serious. I don't see any pressing reason to expedite the removal of Go 1.23, though I do agree that it should be done eventually. Given these items, we should perhaps define a better process for such changes. The desktop team leads with a good example: - when maintainer action is required, a (meta) bug is filed with a list of affected ports (ideally grouped by maintainer) and all affected maintainers in CC. Maintainers then get some time to fix their ports. - after some time, ports that haven't been fixed are deprecated and the change is landed if appplicable We could also add a new macro (maybe FIXME) to tell the maintainer that some action needs to be taken, without giving false notices of impending doom to users. This macro could come with a timeout, after which FIXME is changed to DEPRECATED, indicting that we do not believe that a fix will be forthcoming. Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachmentshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aTQnP6fp8Mdnt1lD>