Core Infrastructure Initiative Best Practices badge
Jump to navigation Jump to search
This is a page to document MediaWiki's compliance with https://bestpractices.coreinfrastructure.org/
Stuff that we do, should generally be documented in the appropriate places for the respective topic.
Stuff we don't do yet, or are not sure if we do yet
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.
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
- firstname.lastname@example.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
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
- Does https://scrutinizer-ci.com/g/wikimedia/mediawiki/ help? If so, can we do the same for all (relevant) repositories?
- It is SUGGESTED that this policy on adding tests be documented in the instructions for change proposals.
- 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. Done
- 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?
- Apparently we're doing well enough.
- 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. Done
- 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 email@example.com
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.
- For non-security static analysis, we run Phan and CodeSniffer on every commit
- We are working on our own custom security static analysis tool, which runs as part of Phan: phan-taint-check-plugin. It is currently running on many extensions, but is not yet running on core.
- Historically we used veracode - phab:T110617.
- Some repositories appear to use the PhpStorm static analysis every now and then.
- It is SUGGESTED that static source code analysis occur on every commit or at least daily
- It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
- 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. Done
- How about wikidiff2?
- It is SUGGESTED that the software include many run-time assertions that are checked during dynamic analysis.
- Unmet i guess?
- 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
drop database mywiki;and
rm -rf mediawiki;)
- N/A kind of ish. Unistall instructions are
- 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 phab: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.
- Some reference texts are mentioned that we don't seem to care much about.
- https://wiki.debian.org/UpstreamGuide is more like what we're used to check