Date: Mon, 21 Jun 2021 13:39:12 +0200 From: Michael Gmelin <freebsd@grem.de> To: Stefan Esser <se@freebsd.org> Cc: freebsd-ports@freebsd.org, Mathieu Arnold <mat@freebsd.org>, Simon Wright <simon.wright@gmx.net> Subject: Re: Bind 9.16.17 update built for packages? Message-ID: <0C62DFCC-EBB5-4915-9023-51343C24A44E@grem.de> In-Reply-To: <dcc64dd1-50ab-2efa-52e2-32127d849391@freebsd.org> References: <dcc64dd1-50ab-2efa-52e2-32127d849391@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 21. Jun 2021, at 13:26, Stefan Esser <se@freebsd.org> wrote: >=20 > =EF=BB=BFAm 21.06.21 um 09:49 schrieb Simon Wright: >> Indeed "these things they do 'appen!" :) Is it possible/worth adding a >> note to UPDATING to not upgrade to 9.16.17? >>=20 >> Something like this: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 20210621: >> AFFECTS: users of bind916 9.16.17 >>=20 >> ISC have issued a warning to users to not upgrade to this version of >> bind916 due to bug in the lookup tables which is likely to cause >> operational errors for most users. >>=20 >> https://gitlab.isc.org/isc-projects/bind9/-/issues/2779 >>=20 >> The issue does not exist in 9.16.16 and is fixed in 9.16.18, please wait >> for that package to be released before upgrading. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Or probably better, roll changes back to remove the faulty package? > I'd think a mechanisms that allows to purge packages with known > vulnerabilites should be provided. >=20 > But there is the issue of dependent packages that will not install > or update unless the dependency is resolved. Those packages need > to be quickly rebuilt, and together with the updated repository > catalogue pushed to the mirrors. >=20 > I do not know whether emergency pushes to mirrors can be performed, > but IMHO we should not distribute packages with significant security > issues via the servers under our direct control and the mirrors. >=20 > The deletion of vulnerable packages even if dependencies and the > repository catalogue cannot be updated at the same time might be > appropriate as an emergency measure in highly critical cases. >=20 > Anyway, AFAIK such an mechanism is not currently implemented and IMHO > it should be designed and rolled out in coordination with mirror > operators (if they need to be involved). >=20 Couldn=E2=80=99t this be implemented in pkg at the client side (which alread= y has =E2=80=98pkg audit=E2=80=99) to use the vulnerability database to prev= ent installation of vulnerable packages (which then would also allow overrid= ing with a flag, as sometimes one really needs to install a package anyway)?= This would basically mirror what we already do in the ports tree. Best, Michael > Regards, STefan >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C62DFCC-EBB5-4915-9023-51343C24A44E>