+1, does not seem like a worthwhile feature for the cost and complexity it requires in the critical path of saving edits.

It doesn't enable or improve anything for the end-user (catching abusive contributions). Anything it would help to catch, one can also catch as easily (or easier) without using this feature.

Change 528540 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Ban variable variables

https://gerrit.wikimedia.org/r/528540

@Daimona, I think we should run a query to make sure no WMF wiki already uses this feature, before disabling it. Can you take the lead on that subtask?

In T229947#5401173, @Huji wrote:

@Daimona, I think we should run a query to make sure no WMF wiki already uses this feature, before disabling it. Can you take the lead on that subtask?

Is any special access needed to be able to query the abuse_filter tables?

You can query public filters like this but (a) you cannot query private filters, and (b) this would require running the query for hundreds of wikis one at a time.

Therefore, we have historically used the help of those WMF folks with DB access in situations like this. We will give them the query in a private Phab Task, they will run it against the DB (hence the result also including private filters), and then we modify the filters as needed. In wikis where Global Sysops can edit the filters, I do the edits myself (I am a Global Sysop solely for that reason). In wikis where Global Sysops do not have this right (which includes most major Wikipedias like English and German) we ask the local admins to make the edits.

I am doubtful that set_var is used on more than a handful of filters overall, and I am doubtful that any of them uses it with dynamic variable names. But better safe than sorry.

Here is the thing tho: if we only want to allow literal strings as the first parameter, then what is the point of having set_var at all? We already can use the variable := value syntax for that.

I think we should allow set_var to accept a string as the first parameter, but not allow it to accept an "expression" as the first parameter.

So this would not be allowed:

set_var( page_title + '_my_string' + ( page_namespace == 0 ? 'main' : 'foo' ), 'myVarValue' )

But this would:

var_name := page_title + '_my_string' + ( page_namespace == 0 ? 'main' : 'foo' );

set_var(  var_name, 'myVarValue' )

In T229947#5401173, @Huji wrote:

@Daimona, I think we should run a query to make sure no WMF wiki already uses this feature, before disabling it. Can you take the lead on that subtask?

Yeah, probably. I can do next week, or feel free to open it if you want.

In T229947#5402485, @Huji wrote:

[...] and then we modify the filters as needed. [...] Global Sysops [...]

I suggest that we try to restart the discussion about the global abusefilter managers group on meta. I was thinking to do that next week, and maybe write on tech news. ATM there are several tasks for which we'd need those rights.

I am doubtful that set_var is used on more than a handful of filters overall,

Agreed

and I am doubtful that any of them uses it with dynamic variable names. But better safe than sorry.

Ditto

In T229947#5402491, @Huji wrote:

Here is the thing tho: if we only want to allow literal strings as the first parameter, then what is the point of having set_var at all? We already can use the variable := value syntax for that.

In fact, IMHO there's no point. It'd just be an alternative syntax for those who prefer to write assignments like that. Removing it altogether would be even more painful.

I think we should allow set_var to accept a string as the first parameter, but not allow it to accept an "expression" as the first parameter.

That's what the patch does.

But this would:

var_name := page_title + '_my_string' + ( page_namespace == 0 ? 'main' : 'foo' );

set_var(  var_name, 'myVarValue' )

It's not allowed with my patch, and that's what I'd like to drop support for.

In T229947#5402592, @Daimona wrote:

I suggest that we try to restart the discussion about the global abusefilter managers group on meta. I was thinking to do that next week, and maybe write on tech news. ATM there are several tasks for which we'd need those rights.

Can you please create a parent task for them and/or a tag? It'd be best to have an easy way to keep track of these. Also, can you please subscribe me to them? Perhaps I can use my Global Sysop right for this purpose for now?

I am in favor of having the discussion restarted. Please {{ping}} me there too.

In T229947#5403216, @Huji wrote:

In T229947#5402592, @Daimona wrote:

I suggest that we try to restart the discussion about the global abusefilter managers group on meta. I was thinking to do that next week, and maybe write on tech news. ATM there are several tasks for which we'd need those rights.

Can you please create a parent task for them and/or a tag? It'd be best to have an easy way to keep track of these. Also, can you please subscribe me to them? Perhaps I can use my Global Sysop right for this purpose for now?

I am in favor of having the discussion restarted. Please {{ping}} me there too.

Created T230263. I'll add other subtasks in case I forgot any of them. And I'm also going to restart the rfc.

We can move on per T230262#5407225.

In T229947#5402485, @Huji wrote:

You can query public filters like this but (a) you cannot query private filters, and (b) this would require running the query for hundreds of wikis one at a time.

Therefore, we have historically used the help of those WMF folks with DB access in situations like this. We will give them the query in a private Phab Task, they will run it against the DB (hence the result also including private filters), and then we modify the filters as needed. In wikis where Global Sysops can edit the filters, I do the edits myself (I am a Global Sysop solely for that reason). In wikis where Global Sysops do not have this right (which includes most major Wikipedias like English and German) we ask the local admins to make the edits.

I am doubtful that set_var is used on more than a handful of filters overall, and I am doubtful that any of them uses it with dynamic variable names. But better safe than sorry.

So I guess there is nothing I can do to help at this point, since {P8894} is private

In T229947#5407961, @DannyS712 wrote:

In T229947#5402485, @Huji wrote:

You can query public filters like this but (a) you cannot query private filters, and (b) this would require running the query for hundreds of wikis one at a time.

Therefore, we have historically used the help of those WMF folks with DB access in situations like this. We will give them the query in a private Phab Task, they will run it against the DB (hence the result also including private filters), and then we modify the filters as needed. In wikis where Global Sysops can edit the filters, I do the edits myself (I am a Global Sysop solely for that reason). In wikis where Global Sysops do not have this right (which includes most major Wikipedias like English and German) we ask the local admins to make the edits.

I am doubtful that set_var is used on more than a handful of filters overall, and I am doubtful that any of them uses it with dynamic variable names. But better safe than sorry.

So I guess there is nothing I can do to help at this point, since P8894 is private

See T230262#5407225

Change 528540 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Ban variable variables

https://gerrit.wikimedia.org/r/528540