Re: Modularity and needed changes on CVE handling side?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for the delay - for some reason I didn't get the email (fresh subscription, so maybe that's why) so replying through the web... 

> On Fri, May 26, 2017 at 10:25 AM, Stanislav Ochotnicky
> <sochotnicky(a)redhat.com&gt; 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.

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.
 
> I'm not sure if that's feasible due to the number of modules and RPMs
> they contain.

I kinda agree - I'd expect *some* tooling to be necessary to make all of this somehow manageable. Hence this thread...

> I would expect that modules are like YUM repositories in the sense
> that they are rebuilt automatically.  Some tracking tool will be
> required to flag outstanding builds and known-vulnerable modules (due
> to their RPM contents).  I think the only way to tackle this is to
> track, in a machine-readable fashion, the set of vulnerable package
> versions, similar to what Debian does:
> 
>   https://security-tracker.debian.org/tracker/

You are right in that modules are basically yum repos. But one repo will easily contain multiple modules - with same rpms (with different releases - one for each module). Expectation is I believe - there will be one F27 "yum repo" (per arch) but it will contain modulemd metadata for all different modules.

There's also the freshmaker project (part of Factory 2.0) which aims to handle these rebuilds at least to some degree:
https://pagure.io/freshmaker/

But I guess what we're talking about here is more in the sense of having an overview where if you identify NVR(s) that's vulnerable - the tooling/service would keep nicely display all modules that need a rebuild or provide links to updates that have already happened (done by freshmaker perhaps). I'd guess we wouldn't want freshmaker to also provide the user-friendly UI like this - but instead prefer to have a separate overview service.

What of all of this would you see as a must-have for a fully-modular release (which wouldn't have "traditional" rpm builds outside of modules)?
_______________________________________________
security mailing list -- security@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to security-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Coolkey]

  Powered by Linux