Auditing (project archive)

Scope
Due to the sheer size of the portage tree, it is infeasible for this project to be able to audit all the packages. The system of prioritizing is based on the time, risk factor, motivation and skills necessary to audit a given package.

Tools
There are several packages available within the portage tree which are designed to aid source code audits. Some of the these include:



Each of the general scanning tools will include output describing the flaw detected, and possibly giving advice on how the code can be fixed. For example the following is taken from the output of RATS describing the dangers of getenv: "Environment variables are highly untrustable input. They may be of any length, and contain any data. Do not make any assumptions regarding content or length. If at all possible avoid using them, and if it is necessary, sanitize them and truncate them to a reasonable length."

If you need any further advice on how to correct a hole which has been reported you should study a book on programming securely, such as the Secure Programming for Linux and Unix HOWTO by David A. Wheeler or the C Secure Coding Standard by CERT (Remember that when reporting security issues a patch closing the hole is greatly appreciated).

Submitting found flaws
When you find a vulnerability, you should write a vulnerability description and submit it for peer-review as a new security bug (with "Gentoo Security" as product and "Auditing" as component, restricted to Gentoo Security). Other auditors (and security team members) will double-check what you found, ensure that it is indeed a bug with a security impact.

When it has been thoroughly peer-reviewed, it will be cleared to go upstream as a "Gentoo Security Audit Subproject" sighting. Depending on its severity and how the package is common amongst distributions, it might need to be coordinated with vendor-sec for coordinated release and CVE number attribution.