On 08/01/2018 01:41 PM, Daniel P. Berrangé wrote:
On Wed, Aug 01, 2018 at 10:33:11AM +0530, Huzaifa Sidhpurwala wrote:
> On 07/31/2018 08:33 PM, Rex Dieter wrote:
>
>>> 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
>>
>> I don't think this is practical, we'll lose half the distro (are at least
>> large chunks).
>>
>> Initially, such a proposal may be possible if generally limited to leaf
>> packages.
>>
>
> So, i did some analysis of the number of packages which would be
> actually removed if we allowed this policy. I generated a list of open
> CVE bugs against X-2 which in this case is Fedora-26 and i got the
> following list:
>
>
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>
> If you extract the list of components ,it yields 57 unique components.
> out of that components like xorg-server etc would probably be in the
> critical list.
binutils is in the list, and without that, we won't have a distro at all !
Yes, that is why the concept of critical pkgs, binutils and others would
obviously be on that list, which means, they cannot be dropped from the
distro.
Chances are though, that the bugs were fixed in upstream and so
available
in newer Fedora version, so merely F26 left unfixed and the BZ status
outdated. I imagine this probably applies to most open CVEs against
RPMs which have an active upstream community. Its the ones with dead
upstream that and not fixed in Fedora that would be the serious concern.
If Newer fedora is fixed via rebase, the older trackers should be closed
with appropriate resolution and comments. I am not asking all the
security issues to be resolved in each version of fedora, i am merely
asking for proper bookkeeping so that our users can make an informed
decision.
Regards,
Daniel
--
Huzaifa Sidhpurwala / Red Hat Product Security Team