On Mon, 29 May 2017 11:42:49 -0000 Stanislav Ochotnicky wrote: > > On Fri, May 26, 2017 at 10:25 AM, Stanislav Ochotnicky > > <sochotnicky(a)redhat.com> wrote: > > > > Is it possible to fix a module in isolation? Or would the fix have to > > be applied to its constituent RPMs? > > Right now the fix would have to first go into the rpms which would be > normally shipped through Bodhi. Idea long term seems to be that > Fedora would be completely modular so there wouldn't be traditional > rpms shipped if they are not part of a module. I still agree with Florian here - it's reasonable to track affected components at their source (srpm / dist-git branch). Automation needs to take care of knowing which modules bundle which components, and hence figuring out which modules need rebuild if some change is applied to the source. Note that I do not think this problem is specific to security fixes - it's the same problem for bug fixes. I also had an impression the automation part was on the list of things that are required for modularity to happen. > Generally - don't expect there will be a "single rpm with fix for > CVE-1234 in F27" but rather "several rpms - each with different NVR > based on which module they were part of for given CVE fix. They > could/would all still likely be built from the same dist-git branch - > but due to module macros end with with different release tags. As noted above, that's something automation needs to keep track of. Asking folks to handle that manually is unreasonable. What will require a change is tracking of multiple versions of a component in one Fedora version. E.g. assume that F2x will have 2 versions of openssl - openssl-1.0.2 and openssl-1.1.0. Do we already have a concrete information on how that's going to be handled in various systems (BZ, dist-git, ...)? -- Tomas Hoger / Red Hat Product Security _______________________________________________ security mailing list -- security@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to security-leave@xxxxxxxxxxxxxxxxxxxxxxx
