You are browsing a read-only backup copy of Wikitech. The live site can be found at

Configuration files/PrivateSettings

From Wikitech-static
< Configuration files
Revision as of 00:12, 18 July 2014 by imported>CSteipp (→‎$wmgCaptchaSecret: link to Generating CAPTCHAs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

PrivateSettings.php holds passwords and other non-public information. It's stored in a private git repo.

Resetting these values

In the event that PrivateSettings.php is made public, here is a list of passwords that need to be reset, and the process to do it.




Used in
  • Web installer password - only need to know the current version when doing a reinstall
  • MWCryptHKDF - source of secret entropy for generating random numbers. A leak will make random numbers using this slightly more predictable
  • Key for hmac in SpecialRunJobs::getQuerySignature() - what does this do?
  • Hash of CheckUser email address - So old versions should may need to be retained to make brute forcing those hashes possible
  • Default for wgOAuthSecretKey - A random string for each consumer in the db is hmac'ed with this key to generate the Consumer's shared secret. Consumers who use HMAC signatures need to be notified if this value is reset, as their connected apps will no longer function.
  • Validation key in FlaggedRebs/RevisionReviewForm::validationKey() - what does this do?
  • Hashed to generate secret in AntiBot/AntiBot::getSecret() - It's unsure what the AntiBot private plugins do with this
  • Translate Extension hashes it with getUser()->getName(), and sets as 'userip' in TranslationHelpers::makeGoogleQueryParams() - It seems like this would have serious privacy impact if the key is leaked to Google.
To Reset

Reset immediately on compromise, but keep a copy of the old value accessible for CheckUsers. Notify OAuth consumers that they need to reset their shared secret before they can use it.


Unused in core, no significant use in extensions


Used to disable captcha solving. Compromise could lead to brute forcing.

To Reset

Reset soon after compromise. Do we have any tools/bots relying on this?


Mixed into hash with captcha answer, used to validate correct captcha responses. Resetting will invalidate all current captcha answers.

To Reset

Regenerate captcha corpus in swift, then reset secret and point to new corpus simultaneously. Only users in the midst of solving a captcha when the switch happens will be affected (have to retry the captcha solve).


Username and key for connecting to swift

To Reset

Create a new swift user/key, then update the PrivateSettings to use the new credentials. Should be no end user impact.

$wmgMFRemotePostFeedbackUsername / $wmgMFRemotePostFeedbackPassword

Formerly used by MobileFrontend, but should be removed from PrivateSettings now.


A wiki account password (for the $wgNotificationUsername account), used to login to remote wikis and make a notification edit when certain events happen.

To Reset

Should reset this immediately on compromise, since it's a login to a valid wiki account. Should be able to create a new user account on each wiki with the Translate extension, then update $wgNotificationUsername and $wmgTranslationNotificationUserPassword to use the new account, with no user impact.

$wgDBuser / $wgDBpassword

Database username and password

To Reset

Create a new user/password in the database, then update PrivateSettings with the new value. Should have no user impact.


The Auth password for connecting to the Redis servers

To Reset

There isn't a graceful way to reset it, however the impact of leaking this password is low (Redis servers should not be accessible from outside the cluster). For now, you have to reset the password in redis.conf, change PrivateSettings, and accept that Redis is inaccessible while this is happening.

$wmgZeroPortalApiUserName / $wmgZeroPortalApiPassword

A wiki user account, used to read Zero-related configuration from the private Zero wiki.

To Reset

Create a new user account on the Zero wiki, then update PrivateSettings with the new credentials. Shouldn't have any end user impact. May also need to reset this value in Varnish config somewhere.