From: santiago@freexian.com 
  
 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 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iHUEABYKAB0WIQR+lHTq7mkJOyB6t2Un3j1FEEiG7wUCaPoyKAAKCRAn3j1FEEiG 
 7+7uAQCKAvVNgU0anBpEHVCQBz6Nx4nC6Q97+NsDoVePpbwQWwD9FYgBOJFLA/tf 
 AfK67wyGalc+mXZTBj5n1iSvsMvDewM= 
 =h6RN 
 -----END PGP SIGNATURE----- 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)