Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:46 AM, Daniel P. Berrangé wrote: > The list of ImageMagick CVEs is horrific - 59 open CVEs - for something > that is often going to be used in a scenario where it is fed untrustworthy > images. exiv2 is pretty concerning too with 19 open CVEs, again for > something often used with untrustworthy input images :-( Yeah, but this is a good example. I haven't looked at the current crop, but I did an update for ImageMagick a while back that fixed a gigantic ton of CVE's. On looking at them however, they were almost all filed from someone running a fuzzer over the source. Upstream then fixed the issues which is great, but in many cases they noted it was very hard/impossible to make an expolit out of them for various reasons. So, just seeing 59 CVE's doesn't tell the whole story. I'm not sure what the answer is here, I'm pretty sure there's no one simple answer. Perhaps a combo of concentrating on the important ones and making things more visible (generate a list of the important ones asking for help once a cycle?). kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/GGFEGN3KP4AK6O7PFEK3XKM4Q23AIGSH/
Re: Making Fedora secure - Package exit policy for security
On Thu, 2018-08-02 at 10:49 +0100, Daniel P. Berrangé wrote: > > > > > > 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. It makes sense but I don't entirely agree. Indeed for these cases we do not have CVEs because most likely no-one is checking these special use cases. We have several insecure crypto libs, several apps that implement their own crypto that would surprise most of us. So my point is that reducing vulnerabilities is the goal here, and CVEs is only one metric of them. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/HVQ25MPBKWQ2KAS5VCBVZUW533ARVQDZ/
Re: Making Fedora secure - Package exit policy for security
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
Re: Making Fedora secure - Package exit policy for security
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/HEUL6HIKCDHVQK6FB47M3SIDJ5JCU3RU/
Re: Making Fedora secure - Package exit policy for security
Nikos Mavrogiannopoulos wrote: > 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. It may be rare but there is such a thing as stable and mature software. It would be unfortunate if high-quality software would be kicked out just because it's not in constant flux. But if there are known security bugs and nobody is fixing them, then yes, dump that junk in a deep-sea trench! Björn Persson pgpULUbmNFVuJ.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/Y6OIUKVRNZNNXJSF5KPVRJPNCRA4VYYX/
Re: Making Fedora secure - Package exit policy for security
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: >> >>> >>> Do we have any analysis showing what would be the fallout if we applied >>> these purge rules today ? ie what packages would be dropped today due >>> to unaddressed CVEs. >>> >> See reply to my previous email. Also i have attached the list here. I >> did some random analysis and came up with the following conclusion: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1493497 >> This one is ftbs on ppc >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1488785 >> This one was actually fixed, but the bug did not close >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1487715 >> This is iamgemagick so one of many cves which are open against it. > > The list of ImageMagick CVEs is horrific - 59 open CVEs - for something > that is often going to be used in a scenario where it is fed untrustworthy > images. exiv2 is pretty concerning too with 19 open CVEs, again for > something often used with untrustworthy input images :-( > You havent seen ImageMagick issues yet :) I agree some of them cannot be fixed, because upstream did not fix them, but atleast there should be some mechanism or marking such pkgs as "has lot of CVEs use at your own risk". Not sure how, i havent thought about that yet. >>> 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. > 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. > 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! > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: Making Fedora secure - Package exit policy for security
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 :( > regards, > Nikos > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org/message/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/ > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/CM7I6AI2O777RQUJYRXUEYYENHT6JRJR/
Re: Making Fedora secure - Package exit policy for security
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_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 >> >> 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/FENPZGAIFU5XSVXKQVNBZ2J457UHOSNV/
Re: Making Fedora secure - Package exit policy for security
On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote: > On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: > > > > > Do we have any analysis showing what would be the fallout if we applied > > these purge rules today ? ie what packages would be dropped today due > > to unaddressed CVEs. > > > See reply to my previous email. Also i have attached the list here. I > did some random analysis and came up with the following conclusion: > > https://bugzilla.redhat.com/show_bug.cgi?id=1493497 > This one is ftbs on ppc > > https://bugzilla.redhat.com/show_bug.cgi?id=1488785 > This one was actually fixed, but the bug did not close > > https://bugzilla.redhat.com/show_bug.cgi?id=1487715 > This is iamgemagick so one of many cves which are open against it. The list of ImageMagick CVEs is horrific - 59 open CVEs - for something that is often going to be used in a scenario where it is fed untrustworthy images. exiv2 is pretty concerning too with 19 open CVEs, again for something often used with untrustworthy input images :-( > > 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. 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. 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. 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. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/XO2BWQQBYOJGVARM45VUKSWU66NOLRPV/
Re: Making Fedora secure - Package exit policy for security
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_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 > > 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 ! 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. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/LTWXRKW3KBKFPFNYMLEQQ6IBULJ4T7MV/
Re: Making Fedora secure - Package exit policy for security
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. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 01:19 PM, Pavel Zhukov 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 > By the time FX is EOL'ed it's too late even for FX+2 to drop the > package. Besides of that CVE could be fixed in FX+2 but not fixed in FX > so the logic should be a way more complex. Sure, the above is just a proposal. We could perhaps drop it while FX+2 is beta etc. I am open to idea, as long as there is a way we could exit the package if it has a consistently bad security record. Also if CVE is fixed in FX+2 and will not be fixed in FX, the bug against FX should be closed as wontfix! >> 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 > Same here. >> >> 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: >> https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/ >> >> [1] https://pagure.io/fesco/issue/1935 >> [2] >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/BXJFXBW4AX5B7QGM2NOS6CFFHSGLBADI/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 05:05 PM, Ondřej Lysoněk wrote: > On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote: >> 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. > Please make sure the process takes into account the fact that packages > may be affected by CVEs in certain Fedora releases only. For example an > older version of a package in F27 is affected by a CVE, but a new > (rewritten) version in F28 is not. It seems the summary of CVE bugs > accordingly contains either the string "[fedora-all]", or "[fedora-27]", > "[fedora-28]" etc. Hopefully that is a reliable source of information. > In this case, the CVE tracker should be fixed as CLOSED:WONTFIX, Automation will only look at open bugs! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/Y3PSYRIVOMETQ67AGMQOBYHEKF73GHPR/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: > > Do we have any analysis showing what would be the fallout if we applied > these purge rules today ? ie what packages would be dropped today due > to unaddressed CVEs. > See reply to my previous email. Also i have attached the list here. I did some random analysis and came up with the following conclusion: https://bugzilla.redhat.com/show_bug.cgi?id=1493497 This one is ftbs on ppc https://bugzilla.redhat.com/show_bug.cgi?id=1488785 This one was actually fixed, but the bug did not close https://bugzilla.redhat.com/show_bug.cgi?id=1487715 This is iamgemagick so one of many cves which are open against it. https://bugzilla.redhat.com/show_bug.cgi?id=1484840 Not sure. > 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? > > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team apt-cacher-ng asterisk async-http-client binutils bzr chromium connman docker-distribution docker-latest emacs freerdp1.2 glpi hive ImageMagick itext jenkins-script-security-plugin ledger libmspack libsndfile lrzip mantis mercurial mesos mingw-binutils mingw-curl mingw-icu mingw-libgcrypt mingw-openjpeg2 mingw-openssl mingw-SDL2_image mongoose newsbeuter nodejs-debug nodejs-fresh nodejs-hawk nodejs-method-override nodejs-mime nodejs-st opencv openjpeg openjpeg2 opennlp passenger php php-Kohana python-scrapy resiprocate rtpproxy rubygem-ox rubygems sleuthkit springframework-amqp spring-ldap tcmu-runner tidy undertow xorg-x11-server ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/L62W4VXEJKI6RLUP6WPX5EPCT6Q7EE6H/
Re: Making Fedora secure - Package exit policy for security
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_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 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. So overall, i dont think its a big problem imo. Theoretically if there is an FTBS, the maintainer would definitely want to do something to fix this. Maybe a lot of these bugs are not really applicable or a rebase already fixed them, so all that is required is to close the bug with an approproate explanation. -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/7X4LIFJD7NTJN4A4Z3JYJPI43SBL7RGA/
Re: Making Fedora secure - Package exit policy for security
On Tue, Jul 31, 2018 at 10:03:16AM -0500, Rex Dieter wrote: > 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 > > I don't think this is practical, we'll lose half the distro (are at least > large chunks). Do we have any analysis showing what would be the fallout if we applied these purge rules today ? ie what packages would be dropped today due to unaddressed CVEs. 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. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/Z2R2ZXJK3QHOIPAM3KMRFJLR4AK34J6T/
Re: Making Fedora secure - Package exit policy for security
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 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. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/2PXSOOOPRNXIBHFUC2RHJFMVGDC6INZI/
Re: Making Fedora secure - Package exit policy for security
On Tue, Jul 31, 2018 at 09:09:58AM +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 What do you mean by 'issue is not addressed' here ? Hopefully it is still valid to simply close the issues as WONTFIX or NOTABUG. IMHO for some low or even moderate severity issues it is often wiser to simply wait till next major Fedora release to pick up a rebased upstream release, rather than do a hairy backport which can risk creating as many problems as it solves. This would imply closing Fedora X as WONTFIX, while Fedora X+2 gets a fix still due to rebased version. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/3KJEWYZT2KSRCNTM2XHVZRS3XOMDIGCH/
Re: Making Fedora secure - Package exit policy for security
On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote: > 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. Please make sure the process takes into account the fact that packages may be affected by CVEs in certain Fedora releases only. For example an older version of a package in F27 is affected by a CVE, but a new (rewritten) version in F28 is not. It seems the summary of CVE bugs accordingly contains either the string "[fedora-all]", or "[fedora-27]", "[fedora-28]" etc. Hopefully that is a reliable source of information. Best regards Ondřej Lysoněk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/JXQVT55SMOKIMYT6T5BX3CDAXORNQLLG/
Re: Making Fedora secure - Package exit policy for security
Don't rely on MODERATE or LOW distinctions to drop a package in FX+2. Just drop all unfixed packages with the same policy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/EOQ3DJKOMBGUHDQ66XTL43RZCSV4MAFN/
Re: Making Fedora secure - Package exit policy for security
Huzaifa Sidhpurwala writes: > 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 By the time FX is EOL'ed it's too late even for FX+2 to drop the package. Besides of that CVE could be fixed in FX+2 but not fixed in FX so the logic should be a way more complex. > 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 Same here. > > 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: > https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/ > > [1] https://pagure.io/fesco/issue/1935 > [2] > https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/UPOUU56BRMLWIIUJB3V5WHV6FZKUP2YW/
Re: Making Fedora secure - Package exit policy for security
On Tue, Jul 31, 2018 at 09:09:58AM +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! Hello, first of all, I really like a more formal approach. However: what about an old version of package p in Fedora release X-1 with a CVE; if upstream does not fix it, you'd be expecting to fix this by the package maintainer; that'd require either backporting to an older branch, or upgrading the package to a newer version, possibly breaking packages being dependencies of pkg in an old (or at least released) Fedora version. Not ideal :-/ > > In the end, i would like you leave you all with this parting link: > https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/ This is a different issue. While we can not be sure this won't happen in Fedora, I'd like to focus on one question/issue per thread. Matthias -- Matthias Runge ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/6CGHEU3PI4BW3Q46PHJNZNKCRPZ7H7A2/
