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:49:13PM +0530, Huzaifa Sidhpurwala wrote:
> On 08/01/2018 01:19 PM, Nikos Mavrogiannopoulos wrote:
> > On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote:
> >> Hi All,
> >>
> >> I was asked to bring this issue[1] to the developer community before
> >> FESCO makes a decision.
> >>
> >> In several instances[2] there exists packages in Fedora, in which
> >> package-maintainers did not patch security issues, for multiple
> >> reasons
> >> including 1. non-responsive maintainer 2. issue hard to patch 3. no
> >> one
> >> cares?
> >>
> >> This is a risk for the distribution, our users and community as a
> >> whole
> >> and not to mentioned bad PR :)
> >>
> >> I would like to propose the following:
> >>
> >>
> >> 1. If a CRITICAL or IMPORTANT security issue is open against a
> >> package
> >> in Fedora-X and by the time X is EOL and the issue is not addressed,
> >> proactively remove the package from X+1
> >> 2. If a MODERATE or LOW security issue is open against a package in
> >> Fedora -X and by the time X+! is EOL, the issue is not addressed,
> >> remove
> >> it from X+2
> >>
> >> Note:
> >> 1. Once pkg is patches, it can be rebuild and re-introduced into the
> >> distro
> >> 2. X/X+1 is the best boundary to remove the insecure packages imo,
> >> since
> >> inbetween removals are not possible due to the way mirrors work.
> >> 3. Maintain a list somewhere (automated maybe) of the list of
> >> packages
> >> removed and why.
> >> 4. Have a list of critical pkg, which cannot be removed which will
> >> break
> >> the distro.
> >>
> >> The above is not set in stone, but is open for discussion. Let me
> >> know
> >> what you guys think!
> >>
> >> In the end, i would like you leave you all with this parting link:
> >>
> > 
> > Thank you Huzaifa for bringing that up. I have a talk on fedora and
> > crypto in flock, and my recommendation will be towards having some
> > process to remove old packages from fedora. CVEs were not the drivers
> > there, but the continuous expansion of the crypto core which at the end
> > as you say causes CVEs which no-one addresses. To add to that, we ship
> > several packages which are the result of an internship, thesis,
> > packages which are there just in case and all expand the attack
> > surface.
> > 
> > So yes, I'd support something like that, and even further than that, if
> > there is no update (upstream release) for 5 years, the
> > package+dependencies is marked for removal as well. Cancelling that
> > process would have to go through a fedora committee.
> > 
> Thank you very much for supporting me on this. This proposal has come
> after years of experience in dealing with Security in Red Hat, upstream
> and Fedora itself. Honestly the volume of pkgs in Fedora is disturbing,
> more disturbing are fly-by maintainers, who do packaging for university
> projects etc and then disappear :(

The majority of stuff on the big list of CVEs looks like mainstream
software, that has been present in Fedora for a long time, with long
term maintainers. The kind of packages added as side-effect of academic
projects by fly-by maintainers are likely fairly niche use cases, or
they would have been already added to Fedora. IOW, I don't think fly-by
maintainers are the big problem in our CVE/security handling story here.

For niche software the concern is probably the scale of unknowns. The
majority of CVEs get filed against widely used / well known software
because that is what attracts the attention of security researchers /
bad guys. We've certainly got lots of software in Fedora with many
security flaws that no one knows about because no one is looking for
them, not even their upstreams.

In that sense, /some/ software with lots of CVEs might be considered
more secure than software with no CVEs because it demonstrates that
people are actively working to understand & fix the security of that
software, as opposed to ignoring the hidden problems.

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/HEUL6HIKCDHVQK6FB47M3SIDJ5JCU3RU/




[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