Difference between revisions of "FLOP:CVE Monitoring"

From Funtoo
Jump to navigation Jump to search
Line 10: Line 10:
This is currently pre-release code. README.md is coming.
This is currently pre-release code. README.md is coming.
{{FLOPFooter}}
{{FLOPFooter}}
== Summary ==
Ultimately, not all ebuilds are created equal. Hence they are updated at different rates according to their popularity in the tree of available packages and this is generally fine: packages with a lot of use get updated frequently, and vulnerabilities are generally dealt with. Unpopular ebuilds can languish, and no one really cares. However, unpopular ebuilds with a significant vulnerability should be updated, popular or not, as they represent a potential vector for attack, if they can be installed.
Identifying ebuilds with an associated CVE will bring them to 'head of the queue' for pull requests and updates, which should often be trivial, as the vulnerability is dealt with upstream and released as a new hotfix version. Or, we can fork and provide our own mitigation, merging with upstream again when a new release comes out (if at all).

Revision as of 03:58, January 22, 2020

Created on
2020/01/21
Original Author(s)
d4g33z
Git sources (for cloning)
Link
Status
Reference Bug
FL-6938

Funtoo Linux Optimization Proposal: CVE Monitoring

Let's monitor the Common Vulnerabilities and Exposures (CVE) list and flag packages in the current portage tree accordingly. Posting bugs on jira.funtoo.org for affected packages could be automated to a significant extent.

About the Code

This is currently pre-release code. README.md is coming.



Summary

Ultimately, not all ebuilds are created equal. Hence they are updated at different rates according to their popularity in the tree of available packages and this is generally fine: packages with a lot of use get updated frequently, and vulnerabilities are generally dealt with. Unpopular ebuilds can languish, and no one really cares. However, unpopular ebuilds with a significant vulnerability should be updated, popular or not, as they represent a potential vector for attack, if they can be installed.

Identifying ebuilds with an associated CVE will bring them to 'head of the queue' for pull requests and updates, which should often be trivial, as the vulnerability is dealt with upstream and released as a new hotfix version. Or, we can fork and provide our own mitigation, merging with upstream again when a new release comes out (if at all).