On 2013-10-28 1:43 AM, "Ori Livneh" <o...@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
> o...@wikimedia.org
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-lI 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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
