Re: Making Fedora secure - Package exit policy for security

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

 



On Thu, Aug 02, 2018 at 01:54:21PM +0530, Huzaifa Sidhpurwala wrote:
> On 08/01/2018 02:16 PM, Daniel P. Berrangé wrote:
> > On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote:
> >> On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote:
> >>> Then, from that list of packages, do we have idea of reasons why
> >>> their CVEs are not getting fixed in Fedora. This could perhaps identify
> >>> changes to help with the problem(s), rather than jumping straight to
> >>> the big stick of dropping packages.
> >>
> >> I definitely want to address the core problem here, but i dont want to
> >> go through tens and even sometimes hundreds of bugs to figure out why
> >> they have not been fixed. Shouldnt the package maintainer be doing it in
> >> the first place?
> > 
> > Obviously the responsibility lies with the package maintainer, but look
> > at what Fedora says their responsibility is:
> > 
> >   https://fedoraproject.org/wiki/Package_maintainer_responsibilities
> > 
> > [quote]
> >   Manage security issues
> > 
> >   Package maintainer should handle security issues quickly, and if they
> >   need help they should contact the Security Response Team.
> > [/quote]
> > 
> > The bugs we file against packages have big boilerplate text, but that's
> > focused around the mechanics of submitting updates, and again doesn't
> > give any guidance on how effectively triage the security bugs.
> >
> Those bugs are linked against "CVE bugs" which are filed against
> product-security component. The "CVE bugs" contain details, including
> patches, reproducers, upstream links etc.

Sure, that's helpful once you've decided to try to address the problem,
but I was talking about the step before that. As a maintainer there is
almost always more work needing attention, than there is free time in
the day. Understanding expectations around how quickly bugs need
addressing is a key factor here.

> > Some maintainers are lucky enough to have experience of dealing with CVEs
> > from RHEL work, but many/most are not. The reality is much more nuanced
> > than "should handle security issues quickly". IMPORTANT and CRITICAL rated
> > security bugs must be handled on very different timeframe from LOW rated
> > bugs. The latter would be valid to just wait for a rebase in future Fedora
> > major release and mark CLOSED->UPSTREAM, while the former is something
> > you'd want to urgently backport fixes for into all existing releases.
> > MODERATE bugs get into a grey area where its hard to give a clear rule,
> > as urgency to fix them varies depending on usage context of the package.
> > 
> In any case, putting a comment on the bug, with details like "No patch",
> "i am working on this one", or even "rebased in FEdora28, wont fix in
> f26" is fine!
>
> > So I can't put all blame on the package maintainers for failing to deal
> > with CVEs appropriately, when we're setting them up to fail by giving
> > little-to-no guidance on what's really expected in this area.
> >
> Shouldnt they ask for guidance then? I am happy to write docs/FAQs if
> there are any questions/comments.

Again it is a matter of time. Understand that maintaniers are usually
overworked and so look for the minimal effort path. Given a pile of new
bugs they'll skim through the bug description and pick tasks to attack
based on some tradeoff between what looks most urgent vs time effective
to fix. From this point of view it is more time effective if we provide
clear guidance on expectations around security bugs upfront, rather than
expecting to resort to asking for guidance via email. Asking for guidance
should be the exception.

> > That's obviously not the entire story here though - even with better docs,
> > I'm confident we'd still have a significant problem to consider. Some of
> > this may well be a result of maintainers simply having too many packages
> > to deal with. With the traditional "single owner" model of Fedora package
> > maint there's a tendancy to leave the fixing to the officially assigned
> > owner. For packages that we see a high volume of CVEs against, we perhaps
> > need to work ensure there are multiple maintainers recorded against the
> > package to give some redundancy.
> > 
> How to do that? ie convince people to co-maintain pkgs with high CVE
> loads? given that cves are deterrent to pkg maintainers!

"High CVE loads" is usually just a small part of the bigger "high bug loads"
pictures, which is usually a result of it being a very popular/mainstrema
app. Fedora has set special policies for subsets of packages in the past,
such as the rules around issuing updates for critical path packages.

It is not unreasonable to identify some set of 'security critical packages'
and declare that those must have multiple assigned owners and more stringent
expectations around response time for CVEs.

Fedora has traditionally had a fairly strong 'single owner' oriented mindset
of package maint, but its often been clear that this has downsides, very often
due to the single owner becoming overworked and CVEs are just one example of
the problems. The more we can do to encourage collaborative maint the better
Fedora will be long term.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/4C227TO27MC5A3M2Q6TXWHASJ7N3JQ5B/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux