Hello all,
(This message was part of an internal discussion among the LTS and
security teams, but there is no reason to keep it private. And the
kernel team should also be added to the loop, since their input is
important. So I am sending it again; sorry for those how received it
twice.)
Tobi and I had a chat last Friday to try to conclude the LTS(/ELTS)
strategy for handling firmware-nonfree updates, that has been discussed
since, at least, last year. Here are some notes and a plan that we would
like to suggests, that requires some input from the security team.
Notes, constraints, and summary from the related discussions:
- Updating a firmware file may yield to old kernels not able to load it,
so it may introduce regressions.
- Vendors do not necessarily update (fix) all of the versions for a
given firmware. It is usual that vendors only update latest files when
there are different ABI-related versions.
- To avoid breaking users' ability to use their hardware, we should
avoid dropping old firmware files
- We have very little information about which versions of a given
firmware are affected or not-affected by a vulnerability
- "If the corresponding driver in the (E)LTS suite's kernel requests an
older version, backporting does *not* fix the issue."
- The security team's strategy is to just update specific firmware files
or add a new one if this is the solution documented by the commit.
Conclusions and suggested plan:
- Follow security-team's approach to ignore CVEs in LTS/ELTS, unless
there is 100% assurance about the status of a vulnerability from the
information provided by upstream
- We will also avoid backporting new upstream versions. We will follow a
similar strategy than security team's
- Since in LTS there is a kernel available from the next most recent
release, we could introduce a new package tied to that kernel. E.g.
firmware-nonfree-6.1. Bullseye's firmware-nonfree will remain tied to
linux 5.10.
For ELTS, this would currently mean two different new source packages:
firmware-nonfree-5.10 and firmware-nonfree-6.1.
The main advantage of tying kernel packages to firmware-nonfree packages
is that we could have more assurance that, when we update or add only
firmware files, they can be loaded by their related kernels.
Question for the security team: would you be OK if we introduce a
kernel-versioned firmware-nonfree source package in security.debian.org?
(Note: we already got an "it is OK" answer here).
Still open questions:
- How would be named the binary packages of the new source package?
Probably also reflecting the kernel version in the binary name, like
firmware-$something-6.1
- What Provides/Breaks/Conflicts/Replaces should they define?
At first glance, we should not support multiple kernels at the same
time. This would introduce a lot of complexity. The hypothetical new
binary packages need to overwrite/replace files from the
firmware-nonfree's packages of the same release, and allow to be
replaced during distro upgrade.
- (WIP) Would it be enough to handle the relationship of these packages
as it is done for virtual-packages? This is:
Provides: firmware-$something
Conflicts: firmware-$something
Replaces: firmware-$something
- Does this needs changes in firmware-nonfree as well?
Any thoughts, objections to this suggestion?
Cheers,
-- Santiago
Attachment:
signature.asc
Description: PGP signature