On Thu 01 Jun 2017 11:45:07 AM CEST Tomas Hoger wrote: > 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. Sounds good. So basically the idea is - each component that goes into modules has to have a component in bugzilla. Even if component is in multiple modules it will only have single component in bugzilla. I do wonder how this will work with arbitrary branches work - where dist-git would likely have separate branches for openssl-1.0 and openssl-1.1 in your example. > 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. Sure the rebuilding part itself will be handled by freshmaker project - it's being worked on right now. But we don't have a good grasp of how exactly CVE tracking will differ from current world (if it will at all). >> 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. I am not asking that anyone does this manually. I am asking what will break when the mapping is no longer: one component/bug -> one shipped build but it will be (based on what you said above around having single component in bz): one component/bug-> multiple modules with multiple component NVRs for the same source rpm I bet there are custom things you have that will be affected. We want to help you understanding/preparing for the changes. > 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, ...)? Partially - basically if you can review this change proposal and provide feedback about what we forgot about that might help: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx/thread/SYPV7H3WHXM33B4HZATNR7OXBSLQJATY/ -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Software Engineer, PnT DevOps - Brno PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 Red Hat Inc. http://www.redhat.com _______________________________________________ security mailing list -- security@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to security-leave@xxxxxxxxxxxxxxxxxxxxxxx
