Please enable bot password otrs-wiki.wikimedia.org.
|operations/mediawiki-config||master||+3 -1||Enable BotPasswords on officewiki and otrs_wikiwiki|
- Mentioned In
- T258358: Allow users to use botpasswords at checkuserwiki
T258356: Allow users at all private/fishbowl wikis to use botpasswords
T258355: Allow users to use botpasswords at stewardwiki
T254925: Bot passwords for officewiki
- Mentioned Here
- T254925: Bot passwords for officewiki
T159519: Investigate security concerns on enabling OAuth or BotPasswords for stewardwiki
'wmgEnableBotPasswords' => [ 'default' => true, 'private' => false, 'fishbowl' => false, 'nonglobal' => false, 'foundationwiki' => true, # T205368 ],
It seems it was explicitly disabled for private wikis (presumably at the time it was turned on). Might need some more digging as to why
Database table will also need creating locally on the wikis database...
I could imagine it was not enabled at private wikis because there are usually no bots running there. As things are growing and automation is generally a good idea, it should be enabled on all private wikis if there are no real reasons against.
I'd probably concur. It'll help with cases where there's 2FA and you don't want to be sharing passwords with tools etc
I've tagged Security-Team and we will talk about it at our triage meeting next week to see if there's any concerns with doing this, and to some extent, doing it more widely
It really depends on the security practices of the bot. I believe the lack of infrastructure (administrative and otherwise) led to this setting. All assumption of privacy would be null if bots in say toolforge are holding bot passwords for accessing them.
That is of course a valid concern.
I cannot speak for others, but my intention is to lock the bot account by 2fa and use the bot password with strict IP limit, to get additional IP filter security.
In theory, yes. But it's not something MW does currently. So it would need some work for someone to add the userright, and wire it into MW into the correct places
Currently it's only a wiki level flag of $wgEnableBotPasswords.
Feel free to add a separate task requesting that as a feature :)
No, I don't want to wait for such feature.
I'd say as long as there is no 2fa requirement on these private wikis, anybody can technically share his password, so using bot passwords does not reduce security per se. But it can increase security, so I like to have it.
I'm inclined to agree, though that action would be a violation of the TOS I believe.
Can you outline where you are going to host the bot in this case and such? The best place to host such a thing would be in production alongside the data already, but if you could settle some peace of mind for us here and create some best practice prior art by outlining your intentions that would be welcome and helpful.
I think we should go ahead and enable it. As already mentioned above, it's already widely used at public wikis, and some private wikis might want to use bots.
@Krd If you want to share something non-public, you can go to https://phabricator.wikimedia.org/paste/, click Create paste, then Create privatre paste (WMF-NDA), which would allow you to create a paste available only to people with a valid NDA on file. I think that's enough for the purpose of sharing the details you was asked for.
As said, I can do that, but I don't think too much detail is required anyway.
We can use bots currently on private wikis with username and good passwords. If we had bot passwords, we could enable 2fa on the bot account and limit the bot password to the fixed IP of the private server the bot runs at. This will in any case highly improve security, with likely not any loss.
If you ask me, this is a nobrainer.
I note from T159519: Investigate security concerns on enabling OAuth or BotPasswords for stewardwiki that the Security-Team at one point did actually OK this.
A use case has come up needing/wanting it for officewiki. I think we needt o have a bit more of adiscussion about it as a team