User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 Steps to reproduce: Currently, it's possible for a new user to sign up for an account, and immediately create a lot of bugs very quickly. Additionally, if editbugs is enabled for new users, they can also make lots of edits quickly. Actual results: This request is prompted by this problem: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56816 Expected results: We would like the ability to limit the rate at which changes are made, bugs are created, or comments made. This doesn't completely eliminate the problem, but it limits the damage that one bad actor can cause, giving us far less to clean up after when a bad actor comes in. This feature request is modeled after the rate limiter feature of MediaWiki: http://www.mediawiki.org/wiki/Manual:$wgRateLimits

LpSolit suggested it would be reasonably simple to write an extension for at least modifications. For that, this hook would need to be employed: http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/Hook.html#bug_check_can_change_field To limit bug creation, a hook would be needed for bug_end_of_create or bug_end_of_create_validators. For comments, object_before_set would need to be employed.

Have you considered just not giving editbugs to new contributors? They can still file bugs and make comments - but mass-closing all the bugs filed by one person is very simple, and mass-nullifying their comments is (admittedly a bit harder) one database query. This is the mechanism most public Bugzillas use. I can imagine, though, perhaps, that Wikimedia has principled opposition to the idea of limiting the editing powers of new people? Gerv

Hi Gerv, you're correct that there's principled opposition to the idea of limiting editing powers. While it's probably more of a requirement for us than others, it's still something that anyone running a public repository would benefit from. With rate limiting combined with the ability to quickly and easily revert bad changes (bug 363346) we'd stack the deck in favor of the good guys.

I wouldn't hold your breath for someone else to implement bug 363346 - the age of the bug is an indication of what sort of priority it seems to have. Depending on how you did it, you could rate limit using a single "change counter" attached to a user's account and counting all the changes. Changing 5 fields on 1 bug would be the same as 1 field on 5 bugs. But perhaps that's OK. You reset all the counters every hour, say. However, you would still need exceptions for privileged users because otherwise people couldn't use the "mass change" abilities of Bugzilla to e.g. move all bugs targetted at one release forward to the next one. Another option would be to limit use of the "mass change" UI to a more restricted group of people. (Do we know if that's what your guy used?) Gerv

Good question. I don't know how to tell what they used. There seem to be a few batches of changes with each batch looking identical (i.e. one batch has a particular comment field added and a specific change to the cc list, another batch has a different change to the cc list, etc), so that means it's possible.

A small hack or extension to limit that UI should be pretty easy. Then, they either have to script Bugzilla themselves using some sort of browser add-in or HTTPUnit (probably not worth it for a griefer) or they have to load, edit and submit each bug manually (which gets boring fast). That would be the simplest solution; why not try that, and see if the problem recurs? Gerv

Hmm, isn't "change several bugs" attached to the editbugs right? Because the accounts created yesterday for spam/vandalism don't have that right, we changed that default earlier yesterday before re-enabling self-registration.

Are these new accounts you are talking about? If people don't have editbugs, all they can do is add comments - either in bulk or singly. (The 'change several bugs' feature doesn't require special permissions to use, but of course you can only make changes that you'd be permitted to make individually.) You can change Bugzilla to say that bulk changes require editbugs by hacking the very top of process_bug.cgi. Gerv

Well even without editbugs, editing the CC list is still permitted (just checked with a test account). And that is clearly what this guy did. His changes were limited to comments and the CC list. His two new accounts from yesterday as well as my test account, all created after we turned off editbugs as default for all users, show that editbugs is off. I'm looking at: 214 [% IF bugs.size > 1 && caneditbugs && !dotweak %] 215 <a href="buglist.cgi?[% urlquerypart FILTER html %] 216 [%- "&order=$qorder" FILTER html IF order %]&amp;tweak=1" 217 >Change&nbsp;Several&nbsp;[% terms.Bugs %]&nbsp;at&nbsp;Once</a> 218 | 219 [% END %] in http://mxr.mozilla.org/mozilla/source/webtools/bugzilla/template/en/default/list/list.html.tmpl and 987 if (!$user->in_group('editbugs')) { 988 foreach my $product (keys %$bugproducts) { 989 my $prod = new Bugzilla::Product({name => $product}); 990 if (!$user->in_group('editbugs', $prod->id)) { 991 $vars->{'caneditbugs'} = 0; 992 last; 993 } 994 } 995 } from http://mxr.mozilla.org/mozilla/source/webtools/bugzilla/buglist.cgi which seem to indicate that one needs editbugs to get mass bug changes. Or am I misreading something? And thanks for your patience btw.

The code snippets you show make it so that you need editbugs to see the mass-change UI; that's not quite the same thing as needing editbugs to actually make such changes, although hacking up the URLs by hand would be tiresome. You are quite right: editing the CC list and adding comments are the two things an unprivileged user can do (on bugs they didn't file) by default. There was some talk of restricting unprivileged users to only _adding_ CC list members and not removing them, but I can't find the bug relating to that. We had a persistent troll here for a few weeks, where we were chasing him around. If the accounts he creates have a pattern (e.g. all at the same domain), you can put a negative regexp in the parameter which says who can create accounts, and ban him that way. (This is made complex by the fact that gmail allows for arbitrary dots and so on, giving you multiple addresses for one mailbox). Or, you can try IP address/block banning, but if he has access to proxies or hacked boxes, he can get around that. In the end, ours just went away; we never came up with a particularly good banning algorithm. So I don't have great wisdom to share... It would be much easier to write a tool which reversed comment-and-CC damage than it would be to write one which reversed arbitrary changes. So at this point, that might be the right route. Deleting comments entirely is probably not recommended, but you can turn them blank without worrying about breaking DB integrity. Gerv

(In reply to Gervase Markham [:gerv] from comment #10) > .. > There was some talk of restricting unprivileged users to only _adding_ CC > list members and not removing them, but I can't find the bug relating to > that. bug 28849?

John: yes, that's it. Thanks for the tip :-) Ariel: I suggest that that's another patch you might want to take. Gerv

One reasonable solution here would be to do general DoS protection by watching how recently a user has taken any action, and then putting in an exponential backoff for them doing further actions, that triggered after too many actions were taken. You could start this off as an extension, and if it proved worthwhile, we could take it upstream as general DoS protection.

Patch to make editbugs group necessary to add or remove arbitrary CCs. Self can still be added or removed.

Comment on attachment 577706 [details] [diff] [review] update patch against trunk to tighten up editbug This patch has nothing to do with this bug.

Hi Mark, What Max is saying is: thanks very much for submitting a patch, but perhaps it would be good to file a new, more tightly-scoped bug to track it :-) However, I think that many public Bugzillas think it's OK for unprivileged users to be able to add CCs of other users, because the normal initial response to "I can't do this, I don't have the privs" is "CC someone who can". Gerv

(In reply to Gervase Markham [:gerv] from comment #16) > Hi Mark, > > What Max is saying is: thanks very much for submitting a patch, but perhaps > it would be good to file a new, more tightly-scoped bug to track it :-) Sure. I was just putting it here since that is what *we* ended up using at Wikimedia to fight our vandal. > However, I think that many public Bugzillas think it's OK for unprivileged > users to be able to add CCs of other users, because the normal initial > response to "I can't do this, I don't have the privs" is "CC someone who > can". Agreed. And we do intend to be generous with the editbugs bit, but a more general fix might be to make this something that bz admins could allow or disallow for editbugs. Hrm... Now that I think about it, allowing anyone with a login to add arbitrary CCs would allow vandals to bomb someone with email. Nevertheless, new bug with updated patch coming up.

(In reply to Mark A. Hershberger from comment #17) > Nevertheless, new bug with updated patch coming up. Bug #706604

Yeah, I do appreciate Mark's contributions, absolutely. But let's keep this bug focused on throttling, not on permissions.