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.
- 1 Stuff we don't do yet, or are not sure if we do yet
- 2 Learning resources
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 - 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