[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7



Control: retitle -1 unblock: docker.io [pre-approval]
Control: tags -1 moreinfo

Hi Arnaud,

On 10-06-2019 06:44, Arnaud Rebillout wrote:
> I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
> before I do that I'd like to ask a question to the release team.
>
> For now in testing we have docker.io 18.09.1, and on top of that I've
> been importing upstream patches to fix RC bugs, because from what I
> understand from the Policy, that's what I should do.

During the freeze we only want targeted fixes for bugs of severity
important and higher (BTS definition) [freeze-policy], yes....

> The 18.09 series of docker is a so-called "LTS", and that's exactly why
> it's THIS release in particular that I targeted for Buster, rather than
> a more recent release. Every now and then upstream releases a new dot
> release, the latest to date is 18.09.6 (released in May).

... but it's possible that new upstream releases *are* targeted bug
fixes. However, ...

> According to the upstream changelog, these are mostly fixes. And to get
> an idea of the volume, between 18.09.1 to 18.09.6, there was 142
> commits, which is rather small compared to the size of docker's codebase.

you as the maintainer have to do the checking. And, "mostly" doesn't
qualify. 142 is *not* small at this moment of the release [last-weeks].

> So it seems to me that upstream really only adds fixes to the 18.09

        ^^^^^^^^^^^ I'd like you to make that assertion much stronger.
Convince yourself 100%, so you can convince us. Is there a LTS policy
that describes what upstream considers acceptable? Does it align with
our bug severity important or higher? Do they test thoroughly? Etc...

> series, and I also think that our users would be better served if they
> could have the latest version of this series in Buster, rather than what
> I'm doing now: only patching 18.09.1 with whatever bug was reported in
> Debian and marked RC, and ignoring all the other bugs that were reported
> and fixed upstream.

I care for bugs that are reported in the Debian BTS, but that doesn't
mean that it's all we care about. We have had multiple unblock requests
where the maintainer was evaluating the changes done upstream and
convinced themselves that they all qualified. By doing the evaluation
they were often able to convince us. In some cases they didn't. I can
only assume that a lot of unblock requests were not filed because the
maintainer couldn't convince themselves.

> Hence I'd like to ask the release team if they think it would be
> suitable to unblock docker.io to allow the version 18.09.6 to be
> uploaded in Buster? Or, better, wait for the next 18.09.7 that will
> include the CVE fix, probably in the next days?

Upstream releases are not acceptable at this moment in the release.
After what I wrote above, obviously with the exception where you can
convince yourself and us that *everything* in the release is qualifying
our freeze criteria [freeze-policy]. However, if at this moment in the
freeze [last-weeks] you need so many changes, I seriously wonder if your
package should be in buster (in general, not necessarily valid for
docker.io)

> Or should I just stick to 18.09.1, and only upload a new debian version
> that only includes the CVE fix?

You'll get an unblock much easier.

Paul

[freeze-policy] https://release.debian.org/buster/freeze_policy.html
[last-weeks]
https://lists.debian.org/debian-devel-announce/2019/06/msg00003.html

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: