This isn't used anywhere. Theoretical code using would gracefully fallback to 'md4' given extra params are ignored by PHP. In terms of future roadmap, I do expect that this algo may have to change one day based on information that might come to light around whether MD4 will remain sufficiently fast and/or sufficiently unique. However, I do not expect that to be so significant in difference that we'd have to remain some callers on MD4 whilst others adopt something else. It seems fine that, if that time comes, to simply switch it and thus consider the algo an implementation detail. Bug: T32956 Change-Id: Ia9e1366b802ac18f439ce0c802189ede0a2c63f0 |
||
|---|---|---|
| .. | ||
| AutoloadGenerator.php | ||
| BatchRowIterator.php | ||
| BatchRowUpdate.php | ||
| BatchRowWriter.php | ||
| ClassCollector.php | ||
| ExecutableFinder.php | ||
| FileContentsHasher.php | ||
| MWCryptHKDF.php | ||
| MWCryptRand.php | ||
| MWFileProps.php | ||
| MWRestrictions.php | ||
| README | ||
| RowUpdateGenerator.php | ||
| UIDGenerator.php | ||
| ZipDirectoryReader.php | ||
| ZipDirectoryReaderError.php | ||
The classes in this directory are general utilities for use by any part of MediaWiki. They do not favour any particular user interface and are not constrained to serve any particular feature. This is similar to includes/libs, except that some dependency on the MediaWiki framework (such as the use of MWException, Status or wfDebug()) disqualifies them from use outside of MediaWiki without modification. Utilities should not use global configuration variables, rather they should rely on the caller to configure their behaviour.