The 1.22 release adds a new configuration variable, $wgRedactedFunctionArguments, that allows administrators of MediaWiki installations to designate function arguments that should be redacted from stack traces. For example: $wgRedactedFunctionArguments[] = array('User::comparePasswords' => array( 0, 1 ) ) This value specifies that whenever the method User::comparePasswords appears in an exception stack trace, the value of the first and second arguments are to be redacted, meaning the string 'REDACTED' is inserted where the argument value would otherwise appear. The case for this feature was made in <https://bugzilla.wikimedia.org/show_bug.cgi?id=30714>. I think that it is a design blunder, and that we should remove it from MediaWiki. The task of making $wgRedactedFunctionArguments comprehensive is hopelessly gargantuan. It would require something like a full trace of the flow of data throughout all of MediaWiki and its extensions. The best case scenario is that the feature is not used. The worst case -- which seems to be materializing, judging by the default value assigned to it in DefaultSettings.php -- is that it is used with a short and chronically out-of-date list of obvious suspects, and that the resultant traces leak private data. This is actually worse than making no attempt at all to sanitize traces, because it is liable to mislead and inspire false feelings of confidence. I think that the proper way to handle low-level operational data like stack traces is to make it clear that it is liable to contain sensitive information, and to make no pretense at all of sanitizing it. If there is a credible need for outputting redacted traces, the output should exclude *all* values, not just the ones that someone remembered to configure. --- "Base access decisions on permission rather than exclusion. This principle...means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation." ("The Protection of Information in Computer Systems", http://web.mit.edu/Saltzer/www/publications/protection/Basic.html) --- Ori Livneh ori(a)wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l