Re: Bind 9.16.17 update built for packages?

From: Michael Gmelin <freebsd_at_grem.de>
Date: Mon, 21 Jun 2021 11:39:12 UTC

> On 21. Jun 2021, at 13:26, Stefan Esser <se@freebsd.org> wrote:
> 
> Am 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?
>> 
>> Something like this:
>> 
>> ============
>> 20210621:
>> AFFECTS: users of bind916 9.16.17
>> 
>> 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.
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/2779
>> 
>> 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.
>> 
>> ============
>> 
>> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 

Couldn’t this be implemented in pkg at the client side (which already has ‘pkg audit’) to use the vulnerability database to prevent installation of vulnerable packages (which then would also allow overriding 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
>