Page MenuHomePhabricator

'skipcaptcha' permission is not assigned to autoconfirmed users on Wikispecies
Closed, DeclinedPublic

Description

On Wikispecies, apparently since yesterday, autoconfirmed users need to enter a CAPTCHA when edits include external links.

For some reason, the 'skipcaptcha' permission has been removed for Autoconfirmed users:
https://species.wikimedia.org/wiki/Special:ListGroupRights

Steps to reproduce:

  1. Go to https://species.wikimedia.org/wiki/Wikispecies:Sandbox
  2. Make sure you are logged in, and you are an autoconfirmed user
  3. Edit the sandbox, and add an external link (e.g. https://www.biodiversitylibrary.org/)
  4. Click the "Publish changes" button

Actual outcome:
It is required to enter a CAPTCHA.

Expected outcome:
The changes should be published without having to enter a CAPTCHA.

Event Timeline

That's...wierd. Skipcaptcha disappeared only from autoconfirmed user group (not confirmed, which is - in Wikimedia's configuration repository - , set as exact copy of autoconfirmed). This is not supposed to ever happen... Also, it's specieswiki-only... Looking, thanks for reporting. PS: Do you remember when it broke, approximately? It can help us debugging.

Fecords my debugging as I did it, isn't structured in any way.

Also, it's specieswiki-only...

FTR, just tested on enwiki (wmf.13) and enwikiversity (wmf.14), can't reproduce on any of those.

Also, this is output from mwrepl.

[urbanecm@mwmaint1002 ~]$ mwrepl specieswiki
Welcome to HipHop Debugger!
Type "help" or "?" for a complete list of commands.

Note: no server specified, debugging local scripts only.
If you want to connect to a server, launch with "-h" or use:
  [m]achine [c]onnect <servername>

hphpd> var_dump($wgGroupPermissions['autoconfirmed']);
var_dump($wgGroupPermissions['autoconfirmed']);
array(11) {
  ["reupload"]=>
  bool(true)
  ["upload"]=>
  bool(true)
  ["move"]=>
  bool(true)
  ["collectionsaveasuserpage"]=>
  bool(true)
  ["collectionsaveascommunitypage"]=>
  bool(true)
  ["autoconfirmed"]=>
  bool(true)
  ["editsemiprotected"]=>
  bool(true)
  ["skipcaptcha"]=>
  bool(false)
  ["abusefilter-log-detail"]=>
  bool(true)
  ["flow-edit-post"]=>
  bool(true)
  ["transcode-reset"]=>
  bool(true)
}

hphpd> ^Dquit
[urbanecm@mwmaint1002 ~]$

Something seems to have explicitly revoked (?) skipcaptcha from autoconfirmed? Why would somebody even want to do that?

Looking on extra things set/loaded for specieswiki.

  • Translate
  • wmgFlowEnableOptInBetaFeature=true
  • wmgUseGlobalAbuseFilters=true

To rule out each possibility, I've looked for another wmf.14 (same as specieswiki) wiki with that setting.

  • Translate) betawikiversity, CNR
  • wmgFlowEnableOptInBetaFeature=true (looks as nonsense, but tested anyway)) frwikiquote, CNR
  • wmgUseGlobalAbuseFilters=true (looks as nonsense, but tested anyway)) enwikisource, CNR

I also tried to downgrade specieswiki to wmf.13 on mwdebug1001 temporarily, to learn if this happened between wmf.13 and wmf.14. Was able to reproduce with wmf.13 => either a backport or something before wmf.13 was branched caused this.

Looked into SAL to learn which backports might be the cause (I believe this would be reported earlier if present before wmf.13), and the following attracted my attention.

SAL from July 17 2019
03:46 tstarling@deploy1001: Synchronized php-1.34.0-wmf.14/extensions/CentralAuth/includes/specials/SpecialMultiLock.php: T227772 (duration: 00m 54s)
03:42 tstarling@deploy1001: Synchronized php-1.34.0-wmf.13/extensions/CentralAuth/includes/specials/SpecialMultiLock.php: T227772 (duration: 00m 56s)
03:00 tstarling@deploy1001: Synchronized php-1.34.0-wmf.13/includes/Permissions/PermissionManager.php: (no justification provided) (duration: 00m 54s)
02:58 tstarling@deploy1001: Synchronized php-1.34.0-wmf.14/includes/Permissions/PermissionManager.php: (no justification provided) (duration: 00m 57s)

It's hard to say with certainity what was deployed, since there is no justification in SAL, but I believe it was https://gerrit.wikimedia.org/r/c/mediawiki/core/+/523840. Tried to revert that patch on mwdebug1001 - skipcaptcha still wasn't assigned to autoconfirmed.

Don't know what to test next. Triaging to High, this is at least high given it affects every user on (at least) one wiki and there is no available workaround.

Urbanecm renamed this task from 'skipcaptcha' permission removed for Autoconfirmed users on Wikispecies to 'skipcaptcha' permission is not assigned to autoconfirmed users on Wikispecies.Jul 21 2019, 12:40 AM

Why didn't I check sooner... I'm sorry, this was done intentionally as part of {T227416} (this is a security task, and is available only to a few of people). This is supposed to be a temporary change, to be reverted as soon as the underlying problem is resolved.

Mentioned in SAL (#wikimedia-operations) [2019-07-21T01:06:09Z] <Urbanecm> Deployed patch for T228574

Stop-gap solution, to lover impact.

this was done intentionally

Where and when were the Wikispecies community notified?

this was done intentionally

Where and when were the Wikispecies community notified?

We do not (and cannot) notify communities about responses to security incidents. Thank you for your understanding.

I noticed that the skipcaptcha right has been assigned (temporarily?) to Autopatrollers. Would it be possible to also assign it to Patrollers?

We do not (and cannot) notify communities about responses to security incidents. Thank you for your understanding.

That wasn't my question. I wanted to know when and where the Wikispecies community were notified about the change in the use of CAPTCHA.

We do not (and cannot) notify communities about responses to security incidents. Thank you for your understanding.

That wasn't my question. I wanted to know when and where the Wikispecies community were notified about the change in the use of CAPTCHA.

I believe that Urbanecm understood what you meant and replied correctly: this is only a temporary security countermeasure. I'm not on the Security Team so I can't tell for sure whether this is the standard practice, but IMHO security countermeasures shouldn't be advertised.

I believe that Urbanecm understood what you meant and replied correctly: this is only a temporary security countermeasure. I'm not on the Security Team so I can't tell for sure whether this is the standard practice, but IMHO security countermeasures shouldn't be advertised.

And yet they posted here "this was done intentionally as part of {T227416} (this is a security task, and is available only to a few of people". So there is an inherent contradiction in saying something cannot be revealed to the community, and on the same page doing so (and indeed, given more detail than would be needed in such a community announcement).

An announcement on Wikispecies to the effect that "We have had to re-enable CAPTCHA for all editors on this project for a short while for technical reasons" would have saved me and several others from wasting our volunteer time trying to find out what was going on.

As it is, the re-enabling was - predictably - noticed and commented on by the community, so any attempt at secrecy clearly failed.

@Pigsonthewing Hi. I am not on the Security-Team but I can confirm this is indeed a very temporary solution that had to be adopted to stop an attack that was targetting Wikispecies and a small subset of other projects. It was an action done to protect the project and that it was going to be reverted as soon as possible. I don't know the exact details of the measures the SecTeam implemented. I think you're right in that perhaps the community should've been given a brief notice that captcha was going to be enabled for all; but on the other hand I think SecTeam didn't expected the attack would last more than a couple of hours,. Also they maybe though that disclosing the measures implemented would not be appropriate at that time. Like I said, I'm not in the SecTeam (nor in any team as I'm just a volunteer with limited access to information) but was one of the respondents in the attack and all I can say is that implementing temporary countermeasures was justified. Let me talk with the ST and see if we can go back to normal. Thanks.

We do not (and cannot) notify communities about responses to security incidents. Thank you for your understanding.

That wasn't my question. I wanted to know when and where the Wikispecies community were notified about the change in the use of CAPTCHA.

As others said, I believe I understood and answered your question correctly. Wikispecies community was never informed. As MarcoAurelio said, we're not on Security-Team, but volunteers with various level of access. This will be discussed with ST on the security task, and rest assured it will be reverted (or released a little) as soon as possible.

I believe that Urbanecm understood what you meant and replied correctly: this is only a temporary security countermeasure. I'm not on the Security Team so I can't tell for sure whether this is the standard practice, but IMHO security countermeasures shouldn't be advertised.

And yet they posted here "this was done intentionally as part of {T227416} (this is a security task, and is available only to a few of people". So there is an inherent contradiction in saying something cannot be revealed to the community, and on the same page doing so (and indeed, given more detail than would be needed in such a community announcement).

Not at all. I only mentioned a task number, and said it's restricted to "a few of people". A task number shouldn't tell anything to you, and the fact it's restricted is easy to say - it isn't a link for you, and if you go to https://phabricator.wikimedia.org/number directly, you'd see something like Access denied.

An announcement on Wikispecies to the effect that "We have had to re-enable CAPTCHA for all editors on this project for a short while for technical reasons" would have saved me and several others from wasting our volunteer time trying to find out what was going on.

It might be considered next time, but I can't promise that. Responses to security incidents are usually needed "right now", and from time to time, there even might be an undefined number of projects affected, because the project name isn't the only criteria which can be used to apply various kind of measures.

As it is, the re-enabling was - predictably - noticed and commented on by the community, so any attempt at secrecy clearly failed.

Yes and no. As said above, Wikispecies is not the only affected project, and there is no (easy) way to tell which projects actually are affected (except going one by one), what are conditions for the measurements to be applied etc.

I noticed that the skipcaptcha right has been assigned (temporarily?) to Autopatrollers. Would it be possible to also assign it to Patrollers?

Yes, for the same duration as the mitigations. Technically, yes, it's definitelly possible, however, I'd like to discuss with ST before touching the mitigations in any other way. It's possible they will be reverted or lowered soon, as was said previously, we know the measures are quite aggressive. Patrollers are significantly smaller group than autopatrollers, and I believe it's easier to grant Autopatroller if it's really a big problem for someone.