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