On 2013-10-28 1:43 AM, "Ori Livneh" ori@wikimedia.org wrote:
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@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I would really like to see stack traces enabled on wmf wikis again. Really really like to see. Seriously, i'll give a unicorn to anyone who makes that happen.
However If that's the goal, it would probably be safer to just totally disable method arguments in the stack trace for the web output only leaving the method names. Imo that would still give enough useful info (a good percentage of the time the exception message in itself is enough info to figure out what's going on or at least triage bug reports into dupes/non-dupes)
That said, redacting might still make sense if we don't give any indication its fully safe. Lots of third party wikis have exceptions enabled in web output regardless. Might as well blacklist the bad things we know as they are going to have it enabled anyhow.
-bawolff