Re: bind9 patch or new upstream version
Hi Roberto
On Sat, 13 Apr 2024 at 01:14, Roberto C. Sánchez <roberto@debian.org> wrote:
>
> Hi Ola,
>
> On Sat, Apr 13, 2024 at 12:49:49AM +0200, Ola Lundqvist wrote:
> > Hi fellow LTS contributors
> >
> > Today I started on bind9 and realized one thing. In bullseye the
> > security update is to release a new upstream version (released as
> > 1:9.16.48-1) instead of patching the old version
> > (1:9.16.44-1~deb11u1). For some reason the version used is -1 instead
> > of ~deb11u1.
> >
> I am not entirely sure why -1 was used, but I can tell you that ~deb11u1
> was not used because the upload went through proposed-updates. It
> appears to also have gone to the security queue, but it isn't clear to
> me why that happened. In any event, an upload to proposed-updates would
> typically need a version like +bullseye1. However, stable already has a
> higher version (1:9.18.24-1), which guarantees that on upgrade from
> bullseye to bookwork the new version in bookworm will take priority.
Thank you.
> Also, looking at security and proposed-updates for stable shows that the
> versions there were also uploaded with -1.
>
> Either way, it doesn't make a difference and it isn't something that we
> should worry about.
Ok
> > Since this is not the normal practice I'd like to check so we have a
> > common agreement that this is the best also for LTS/buster.
> >
> > In this case I think it is the safest method. Trying to pick the
> > individual patches can be risky.
>
> Assuming that you are suggesting that we upgrade buster to the bullseye
> version (9.16.48), then I disagree entirely. We cannot move bind9 to the
> bullseye version.
I had actually not looked that far, yet. I was asking just because
oldstable went from 9.16.44 -> 9.16.48 instead of 9.16.44-y to 9.16.44-(y+1)
with backported patches.
So I wanted to know if there were objections on even going from 9.11.5.x to
something else without patching before I checked too much further.
> > Or do we know any specific reason why we should not go this path?
> >
> In the case of buster we can't do what what was done for stable and
> oldstable. If you look at the versions there, here is what happened:
>
> stable: 9.18.19 -> 9.18.24
> oldstable: 9.16.44 -> 9.16.48
>
> The version in buster is 9.11.5.P4. We cannot upgrade to 9.16.48 without
> risking breaking changes for users.
Right. I was planning to look at what changes were in the oldoldstable
to oldstable
release next to see if it was merely feature addition or risk of
breaking change.
> I haven't looked, but I assume that
> you are asking this question because there is not a new 9.11.x release
> that deals with the current vulnerabilities.
Looks like there is no such version available. There is an 9.11.37 but
that is from 2022 and the CVEs are later so I doubt that they fix the
issues we have CVEs on now.
> If it happens to be the
> case that there is a new 9.11.x release that addresses the
> vulnerabilities, then that is potentially a path we could take.
It does not look so.
> If there
> is not a 9.11.x version that we could migrate to, then we will need to
> carefully backport the patches and ensure that everything is rigorously
> tested.
Right. Looks like I have some patch extraction work to do. :-)
Since this is a high profile package I think it would be good if more
than me do the tests, but that is a later step.
Cheers
// Ola
--
--- Inguza Technology AB --- MSc in Information Technology ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: