You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org
Configuration files/PrivateSettings
![]() | This page may be outdated or contain incorrect details. Please update it if you can. |
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.
$wgDBsqlpassword
$wgSecretKey
- 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.
$wgProxyKey
- Unused in core, no significant use in extensions
$wmgCaptchaPassword
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?
$wmgCaptchaSecret
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).
$wmfSwiftEqiadConfig
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.
$wmgTranslationNotificationUserPassword
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.
$wmgRedisPassword
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.