Core Infrastructure Initiative Best Practices badge

This is a page to document MediaWiki's compliance with https://bestpractices.coreinfrastructure.org/

Current Status: cii best practices in progress 91%

Stuff that we do, should generally be documented in the appropriate places for the respective topic.

Bug reporting process

 * The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
 * No stats on this. Let's try checking a sample of ~25 reports?
 * Probably not.
 * The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.
 * ditto

Vulnerability reporting process

 * The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days.
 * I (bawolff) think this is true, if you exclude bugs that are written by developers as future todo's. But I don't have any stats to back up
 * security@wikimedia.org is an e-mail alias.
 * Usually anything legit gets immediately put into Phabricator.

Automated test suite

 * It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality
 * https://integration.wikimedia.org/cover/mediawiki-core/master/php/

New functionality testing

 * The project MUST have evidence that such tests are being added in the most recent major changes to the project
 * Better than we used to be, probably still not met though
 * It is SUGGESTED that this policy on adding tests be documented in the instructions for change proposals.

Warning flags

 * It is SUGGESTED that projects be maximally strict with warnings, but this is not always practical
 * Maybe an N/A? Maybe Met? This is user controlled in PHP. Most devs put it on, but disable on production.
 * This seems about compiler warnings, testing suite complaints and the like: unclear how it applies to MediaWiki.
 * I was thinking if maybe meant php error_reporting config directive. We also internally have $wgDevelopmentWarnings.

Good cryptographic practices

 * The project's cryptographic software MUST use by default only cryptographic protocols and algorithms that are publicly published and reviewed by experts.
 * This is met to the best of my knowledge
 * The project security mechanisms MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012)
 * This is N/A mostly. Although we do use hashes for some purposes that are less than their requirement (hmac-md5 is used in edit tokens. md5 is used in certain non-security critical places (e.g. in certain cache keys to ensure non-ascii characters aren't used in the cache key). Sha1 is used all over the place, but again in mostly non-security critical locations).
 * The project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
 * N/A. Either the lower layer's job (webserver) for receiving https requests, or the PHP's openSSL extension's job (when making HTTPS requests)
 * The project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are not cryptographically secure
 * There are certain secrets which will use weak randomness if the system doesn't support strong randomness. These should be very rare edge cases. See MWCryptRand::realGenerate.

Publicly-known vulnerabilities fixed

 * Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.
 * Define rapidly? We try to do our best, but we could probably be better.
 * We don't have tools to tell how long it takes nowadays. Can something be extracted from MITRE?
 * The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.
 * Met to the best of my knowledge. If anyone is aware of a public repo with a secret key in it, they should report to security@wikimedia.org

Static code analysis

 * It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment.
 * Security team is in progress looking into this - T110617. This is probably met.
 * It is SUGGESTED that static source code analysis occur on every commit or at least daily
 * Currently once a week, so unmet.

Dynamic analysis
Wikimedia Security Team/ApplicationScanning?
 * It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
 * Unmet
 * It is SUGGESTED that if the software is application-level software written using a memory-unsafe language (e.g., C or C++) then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used with a mechanism to detect memory safety problems such as buffer overwrites.
 * N/A
 * How about wikidiff2 and php-fss?
 * php-fss is abandoned now that both Zend and HHVM have a decent strtr.
 * It is SUGGESTED that the software include many run-time assertions that are checked during dynamic analysis.
 * Unmet i guess?

Future

 * The project SHOULD provide a way to easily install and uninstall the software using a commonly-used convention. Examples include using a package manager (at the system or language level), "make install/uninstall" (supporting DESTDIR), a container in a standard format, or a virtual machine image in a standard format. The installation and uninstallation process (e.g., its packaging) MAY be implemented by a third party as long as it is FLOSS.
 * N/A kind of ish. Unistall instructions are  and   ;)
 * The project SHOULD, if it supports TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. [crypto_tls12]
 * PHP openssl extension is high enough/ webserver high enough, this is met. Maybe its n/a ?
 * The project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources.
 * Met. See 1c927b1df2ac4d
 * The project SHOULD, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies)
 * N/A That's the webserver's job.
 * It is SUGGESTED that the project website, repository (if accessible via the web), and download site (if separate) include key hardening headers with nonpermissive values. https://securityheaders.io/?q=https%3A%2F%2Fwww.mediawiki.org%2F&followRedirects=on
 * Unmet. Content-Security-Policy is sort of being worked on. Public-Key-Pins is talked about T92002 (Also not really a MW level header), X-Frame-Options is only on special pages, and edit pages (unless $wgBreakFrames is true). X-XSS-Protection is currently not set (Maybe it should be?). Strict-Transport-Security is set on Wikimedia websites, but generally considered not mediawiki's responsibility, so not set by MW.
 * It is SUGGESTED that hardening mechanisms be used so software defects are less likely to result in security vulnerabilities.
 * Unmet for the moment, but CSP is being worked on.

Learning resources

 * Some reference texts are mentioned that we don't seem to care much about.
 * http://web.mit.edu/Saltzer/www/publications/protection/Basic.html
 * http://producingoss.com/
 * https://wiki.debian.org/UpstreamGuide is more like what we're used to check