I thought we did this already?..

Ping, can anyone take a look at this? I'm not the only one noticing this (and it's happening in the ChromeOS repo and possibly other repos as well)

Re-triaging because this isn't a one time task, but a policy question.

I'm personally not aware of controls that'd prevent creating a revert. Last I checked, "create revert" functionality in UI is merely sugar on top two Gerrit APIs:
 * create new CL
 * post a message to existing CL

Both actions are normally allowed to users.

However, an ugly hack would be gating the UI action on ability to vote on CQ+1.

tandrii, thanks for retriaging into a better component :)

Yeah, so this kinda comes down to the distinction between "public" and "publicised".

As Andrii says, the Revert button effectively just calls the "upload change" and "post message" APIs, which we obviously allow all members of the public to do, because if we didn't we'd never get any outside contributions at all.

But that doesn't necessarily mean that we have to expose the one-click-revert button to everyone, including spammers/crawlers. Even though they technically have permission to do all the actions it does, we could hide/disable the button for them anyway.

Note that this would be *disabling a default gerrit feature*. Gerrit provides that one-click revert button. While we do run a Gerrit plugin which modifies its behavior (changes the commit message to include lines like "No-Try: true" when appropriate), the button is there for all other Gerrit projects.

So do we believe that revert-spam is a big enough problem to merit using our plugins to disable a default gerrit feature?

As a contributor, I think that the lost engineering time from people dealing with the spam and discussing the issue is already fairly significant. I think if we get multiple reports there are probably a lot of other instances that go unreported.

As an example, one of the spammers I noticed last week actually sent out another revert to someone else, which got +1ed before getting -1ed:

https://chromium-review.googlesource.com/c/chromium/src/+/894244

If this were submitted in that window where it was +1ed, the cost would be higher (someone would have to figure out that it was reverted by mistake etc). I imagine it's just a matter of time before someone reflexively +1s a spam revert and it gets submitted.

Issue 812376 has been merged into this issue.

I also noticed some random attempts of voting CQ+1:
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/924105

Although it should have much lower severity, since the CL must be ready for submission anyway, there are still cases where it could be undesired to submit without confirming with the owner.

https://chromium-review.googlesource.com/#/c/infra/gerrit-plugins/chromium-behavior/+/953330

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/gerrit-plugins/chromium-behavior/+/2eb29612f8c83dc8775f163a3b91947612786314

commit 2eb29612f8c83dc8775f163a3b91947612786314
Author: Aaron Gable <agable@chromium.org>
Date: Wed Mar 07 19:51:37 2018

Don't show Reland and Revert buttons to non-committers

Lots of spam on Gerrit takes the form of drive-by robot accounts
clicking the "Reland" and "Revert" buttons, generating spurious
CLs and sending email to the people who reviewed the original change.

Although we can't prevent non-committers from reverting and relanding
changes (after all, doing so is just creating a new change with
specific content), we can try to cut down on this kind of spam by
only showing those buttons to committers (and the owner of the
original change, of course).

Bug:  810423 
Change-Id: I59b7f95a69088028cdc91b471dd037f44a09bf3c

[modify] https://crrev.com/2eb29612f8c83dc8775f163a3b91947612786314/src/main/resources/static/chromium-behavior.html

Marking fixed, even though may take up to a week to deploy. Can mark Verified then.

Has this been deployed? I'm still seeing bogus-seeming reverts from non-committers, e.g. https://crrev.com/c/979492 reverting https://crrev.com/c/976870 on March 24.

It has been deployed, but it doesn't work fully for ChromeOS repos. At the moment, it is hardcoded to only show the Revert and Reland buttons to people who can vote "Code-Review+1", as opposed to people who can vote "Code-Review+[MAX_VALUE]". Since everyone can vote CR+1 in ChromeOS repos, it doesn't hide the buttons there.

Generalizing this behavior is rather non-trivial.

Should I file a separate bug to track further work that will fix this problem for Chrome OS repositories?

Yeah, that would be helpful. It may end up getting de-duped against another bug for generalizing other chromium-behavior stuff that I swore we had, but I can't find it at the moment. Sorry for the fuss.

Filed issue 826043 to track fixing this for Chrome OS.