firmware-nonfree update

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

firmware-nonfree update

Emilio Pozuelo Monfort-4
Hi Ben,

I have prepared an update for CVE-2018-5383/firmware-nonfree by backporting the
fixed firmware from the upstream repo that I could find. See my two commits in:

https://salsa.debian.org/pochu/firmware-nonfree/commits/jessie-security

I built the packages and compared one of the non-affected packages (qlogic) and
only the changelog has changed. Comparing atheros, the two drivers are updated,
and for intel some of the files are updated. However I see that for intel there
are some drivers that we don't ship in that version of firmware-nonfree, e.g.
ibt-{17,18}-*. For those, I wonder if we should update and ship them. If there's
any user with that hardware, they would need a firmware update I suppose. (It
may be unlikely for old suites to have users with new hardware, however it's
possible and users that don't have it will be unaffected by the new firmware, so
it wouldn't hurt to ship it.)

My branch is for jessie but I can prepare it for stretch too if you think that's
worth it.

Thanks,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Ben Hutchings-3
On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:

> Hi Ben,
>
> I have prepared an update for CVE-2018-5383/firmware-nonfree by backporting the
> fixed firmware from the upstream repo that I could find. See my two commits in:
>
> https://salsa.debian.org/pochu/firmware-nonfree/commits/jessie-security
>
> I built the packages and compared one of the non-affected packages (qlogic) and
> only the changelog has changed. Comparing atheros, the two drivers are updated,
> and for intel some of the files are updated. However I see that for intel there
> are some drivers that we don't ship in that version of firmware-nonfree, e.g.
> ibt-{17,18}-*. For those, I wonder if we should update and ship them. If there's
> any user with that hardware, they would need a firmware update I suppose.
firmware-nonfree is meant to support the kernel version(s) shipped in
the same suite, in the previous release, or in intermediate versions.
So for jessie that's 3.2-4.9 inclusive.  If one of those kernel
versions may request the added files then they should be packaged.
Otherwise it's not necessary - users installing a newer kernel package
from another suite can get the firmware packages from there too.

> (It
> may be unlikely for old suites to have users with new hardware, however it's
> possible and users that don't have it will be unaffected by the new firmware, so
> it wouldn't hurt to ship it.)
>
> My branch is for jessie but I can prepare it for stretch too if you think that's
> worth it.

The current jessie-security version of firmware-nonfree is really a
backport from stretch.  So I would prefer it if you update the stretch
branch first and then merge that to jessie-security.

Ben.

--
Ben Hutchings
friends: People who know you well, but like you anyway.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Emilio Pozuelo Monfort-4
Hi Ben, thanks for the review.

On 05/03/2019 23:00, Ben Hutchings wrote:

> On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:
>> Hi Ben,
>>
>> I have prepared an update for CVE-2018-5383/firmware-nonfree by backporting the
>> fixed firmware from the upstream repo that I could find. See my two commits in:
>>
>> https://salsa.debian.org/pochu/firmware-nonfree/commits/jessie-security
>>
>> I built the packages and compared one of the non-affected packages (qlogic) and
>> only the changelog has changed. Comparing atheros, the two drivers are updated,
>> and for intel some of the files are updated. However I see that for intel there
>> are some drivers that we don't ship in that version of firmware-nonfree, e.g.
>> ibt-{17,18}-*. For those, I wonder if we should update and ship them. If there's
>> any user with that hardware, they would need a firmware update I suppose.
>
> firmware-nonfree is meant to support the kernel version(s) shipped in
> the same suite, in the previous release, or in intermediate versions.
> So for jessie that's 3.2-4.9 inclusive.  If one of those kernel
> versions may request the added files then they should be packaged.
> Otherwise it's not necessary - users installing a newer kernel package
> from another suite can get the firmware packages from there too.

Right, makes sense. I suppose that since the Intel ibt-{17,18}-* firmware is not
present in the stretch package, that we shouldn't add it here. So I limited this
to updating the firmware that was already present.

>> (It
>> may be unlikely for old suites to have users with new hardware, however it's
>> possible and users that don't have it will be unaffected by the new firmware, so
>> it wouldn't hurt to ship it.)
>>
>> My branch is for jessie but I can prepare it for stretch too if you think that's
>> worth it.
>
> The current jessie-security version of firmware-nonfree is really a
> backport from stretch.  So I would prefer it if you update the stretch
> branch first and then merge that to jessie-security.

Ack. I updated stretch here:

https://salsa.debian.org/pochu/firmware-nonfree/commits/stretch

and created a MR:

https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/6

If this looks fine I'd be happy to submit a pu bug for stable, and I'll also
look into an update for jessie.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Ben Hutchings-3
In reply to this post by Ben Hutchings-3
On Tue, 2019-03-05 at 22:00 +0000, Ben Hutchings wrote:
> On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:
[...]

> > (It
> > may be unlikely for old suites to have users with new hardware, however it's
> > possible and users that don't have it will be unaffected by the new firmware, so
> > it wouldn't hurt to ship it.)
> >
> > My branch is for jessie but I can prepare it for stretch too if you think that's
> > worth it.
>
> The current jessie-security version of firmware-nonfree is really a
> backport from stretch.  So I would prefer it if you update the stretch
> branch first and then merge that to jessie-security.
I've merged your changes to stretch, uploaded to stretch, and then
merged stretch to jessie-security.  Let me know if you want to do the
upload to jessie-security or if I should do it.

Ben.

--
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Emilio Pozuelo Monfort-4
On 25/03/2019 18:20, Ben Hutchings wrote:

> On Tue, 2019-03-05 at 22:00 +0000, Ben Hutchings wrote:
>> On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:
> [...]
>>> (It
>>> may be unlikely for old suites to have users with new hardware, however it's
>>> possible and users that don't have it will be unaffected by the new firmware, so
>>> it wouldn't hurt to ship it.)
>>>
>>> My branch is for jessie but I can prepare it for stretch too if you think that's
>>> worth it.
>>
>> The current jessie-security version of firmware-nonfree is really a
>> backport from stretch.  So I would prefer it if you update the stretch
>> branch first and then merge that to jessie-security.
>
> I've merged your changes to stretch, uploaded to stretch, and then
> merged stretch to jessie-security.  Let me know if you want to do the
> upload to jessie-security or if I should do it.

I don't mind either way. We should use -4~deb8u2 rather than -5~deb8u1 so that
we don't (temporarily) have a higher version in jessie than stretch until the
point release.

Emilio

Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Ben Hutchings-3
On Tue, 2019-03-26 at 17:51 +0100, Emilio Pozuelo Monfort wrote:

> On 25/03/2019 18:20, Ben Hutchings wrote:
> > On Tue, 2019-03-05 at 22:00 +0000, Ben Hutchings wrote:
> > > On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:
> > [...]
> > > > (It
> > > > may be unlikely for old suites to have users with new hardware, however it's
> > > > possible and users that don't have it will be unaffected by the new firmware, so
> > > > it wouldn't hurt to ship it.)
> > > >
> > > > My branch is for jessie but I can prepare it for stretch too if you think that's
> > > > worth it.
> > >
> > > The current jessie-security version of firmware-nonfree is really a
> > > backport from stretch.  So I would prefer it if you update the stretch
> > > branch first and then merge that to jessie-security.
> >
> > I've merged your changes to stretch, uploaded to stretch, and then
> > merged stretch to jessie-security.  Let me know if you want to do the
> > upload to jessie-security or if I should do it.
>
> I don't mind either way. We should use -4~deb8u2 rather than -5~deb8u1 so that
> we don't (temporarily) have a higher version in jessie than stretch until the
> point release.
I disagree.  An upgrade should not undo security fixes, if we can avoid
it.

Ben.

--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firmware-nonfree update

Ben Hutchings-3
In reply to this post by Ben Hutchings-3
On Mon, 2019-03-25 at 17:20 +0000, Ben Hutchings wrote:

> On Tue, 2019-03-05 at 22:00 +0000, Ben Hutchings wrote:
> > On Fri, 2019-03-01 at 14:05 +0100, Emilio Pozuelo Monfort wrote:
> [...]
> > > (It
> > > may be unlikely for old suites to have users with new hardware, however it's
> > > possible and users that don't have it will be unaffected by the new firmware, so
> > > it wouldn't hurt to ship it.)
> > >
> > > My branch is for jessie but I can prepare it for stretch too if you think that's
> > > worth it.
> >
> > The current jessie-security version of firmware-nonfree is really a
> > backport from stretch.  So I would prefer it if you update the stretch
> > branch first and then merge that to jessie-security.
>
> I've merged your changes to stretch, uploaded to stretch, and then
> merged stretch to jessie-security.  Let me know if you want to do the
> upload to jessie-security or if I should do it.
I've now uploaded and sent the DLA.

Ben.

--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.



signature.asc (849 bytes) Download Attachment