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)