Any opinions on this @chasemp or others from Security Team?

In T202080#5209386, @greg wrote:

Any opinions on this @chasemp or others from Security Team?

Adding the Security-Team for your feedback. See description.

@mmodell @greg -

I think the Security-Team is fine with open-sourcing this plugin (tagging @JBennett and @Reedy as well). We already do the same for most anti-spam/vandalism tools for MediaWiki. Would this involve making what's currently in /src/config private and just putting some example config file there?

Also n.b. - the Security-Team is still in the active process of cleaning up our team workboard. We're hopeful it will soon be in a place where we can triage new backlog items, tagged tasks, etc. on at least a weekly basis. Until then, pinging one of us on irc/email is probably the best way to get eyes on a task quickly.

Making rPHAVA fully public will expose its full git history avalaible as well as its current contents. Are you sure nothing private or that can defeat the purpose of rPHAVA exists in there? I'd rather keep the repo private. Security through obscurity works.

@MarcoAurelio - a new, public-facing repo could be created to remove any reference to the sensitive config.

@mmodell @greg I'm echoing what @sbassett said above. We are all for this as long as the set thresholds and data is separated from the code. I think it would be great considering how limited these abilities are in phab vanilla. Really have appreciated all of @mmodell's hard work here. Let us know what we can do to move this forward.

Thanks @chasemp and @sbassett! I've created a new repo with no history and included a LICENSE file as well as changing the defaults so that they are not closely related to the current production configuration. Users of the extension will have to do a bit of trial and error to find the tuning parameters that are best for their specific phabricator installation.

https://gerrit.wikimedia.org/g/phabricator/antivandalism/+/refs/heads/master