Bug#930293: unblock: docker.io/18.09.1+dfsg1-7
On 6/13/19 3:31 PM, Paul Gevers wrote:
> 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.
I'll go this way then :)
Thanks for taking some time to give such a detailed answer, not only for
docker.io but more generally to get a better grasp on what's suitable or
not during the freeze.
I won't audit the whole 142 commits, even less convince myself or anyone
about what it brings on the table, so I'll stick to fixing the CVE that
is opened at the moment.
Thanks,
Arnaud
Reply to: