Page MenuHomePhabricator

Debug level set too high on production wiki
Closed, ResolvedPublic

Description

Rich Farmbrough reports on en.wp that he managed to get the following message recently, but with actually data rather than "[redacted]":

A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: UPDATE user SET user_name = '[redacted]',user_password = '[redacted]',user_newpassword = 'redacted',user_newpass_time = '[redacted]',user_real_name = ,user_email = 'redacted',user_email_authenticated = '[redacted]',user_touched = '[redacted]',user_token = '[redacted]',user_email_token = '[redacted]',user_email_token_expires = '[redacted]' WHERE user_id = '[redacted]' Function: User::saveSettings Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.0.6.48)

Clearly, this is a debug message that shouldn't be visible on a production wiki such as en.wp (regardless of the underlying problem) - either the debug level is set too high, or that message evades the privacy/debug filter.


Version: wmf-deployment
Severity: normal

Details

Reference
bz36602

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:28 AM
bzimport set Reference to bz36602.
bzimport added a subscriber: Unknown Object (MLST).

Tried, but could not reproduce this. Still the message shouldn't show up.

Thehelpfulonewiki wrote:

Where did you see this? Can he reproduce the error?

(In reply to comment #2)

Where did you see this? Can he reproduce the error?

It's on VPT. I've asked, no response yet.

Meanwhile, Tim Starling has said there:

It's hard to tell what the cause of this was without knowing the URL,
but it's possible that it was an exception message shown through api.php
due to $wgShowExceptionDetails being set to true. It's probably not a serious
security vulnerability, since such messages are sent with Cache-Control:
private, but again, it's hard to be sure without having details about where
it came from. We decided to turn off $wgShowExceptionDetails to be on the
safe side, the reasons it was turned on are mostly no longer relevant.

So if can't repro, I think we're fine to close fixed without prejudice to reopening...?

(In reply to comment #3)

So if can't repro, I think we're fine to close fixed without prejudice to
reopening...?

agreed

Changing to "FIXED" since there does seem a semblance of a fix here, and it's just nicer on everyone if it gets closed that way.