Oh wow. I enabled user registration on one of my Forgejo test instances, and two weeks later I have a over 200 spam accounts.

I really need to sit down and implement some of the anti-spam measures I had in mind.

What did I have in mind for Forgejo anti-spam measures?

Basically a hook that executes custom Lua code on certain actions (like user registration, user profile updates, etc). It would be able to keep its own state (undecided how). The result of the called Lua function would result in either letting the operation pass, it could result in denial, or in purging the user.

Custom lua code allows a whole lot more customisation, while still allowing us to provide reusable modules. Reusable modules like detecting - and remembering - spammy links, and preventing their use in the future.

We'd also provide a "Report spam" button: for regular users, that'd trigger the spam filter, but instead of performing the action in the end, it'd report the result to the instance admins (it would not perform the same scan multiple times; if the reported profile didn't change between reports, it would not scan again, but would increment a counter, and only report to the admins if no action has been taken for some time). For admins, it'd perform the scan and remove the offending account if need be.

Think of this a bit like rspamd, but embedded within Forgejo.

Now... why embedded instead of a separate service? Because one of the good things about Forgejo is that it's a single binary (if you don't want CI, and you're using SQLite), and embedding the anti-spam tool allows us to block spammy actions as soon as possible, without needing to care about inter-process communication errors. Embedding it also allows us to have an integrated UI for it, and reuse a bunch of code from Forgejo.

Why Lua? Because Lua is reasonably easy to embed, and is a reasonably simple language to write this kind of code in. It doesn't need to be compiled, it's fairly small, and has good documentation.

Why Lua, instead of building something Forgejo specific that doesn't need writing a small program?

Flexibility. Using Lua will - potentially - allow reaching out to external services or resources, and is more flexible.

We can still provide convenient defaults one can click together on the Forgejo UI, without writing any code.

Furthermore on the why lua topic: because I already experimented with embedding Lua in Forgejo, and had good success with it.

I also experimented with embedding JS and WASM, and that was a whole lot more complicated, and required considerably more resources and massaging.

Lua is simple, both to embed, and to write code in. It's also fast enough for the job at hand.

@algernon Spam, uh, finds a way

@alesi This gif sent my brain down a weird path, contemplating the deep philosophy behind the idea that "life = spam". There's a great (read: twisted & unhinged) story that'll grow out of it.

Thanks!

When will I have something to show? I don't know! I have a whole lot of stuff on my plate right now. I'd love to work on this, because I think this would be a terrific aid for anyone running a public Forgejo instance (especially if they run a big one like Codeberg).

I also think it would be fairly simple to implement too. Easier than the soft quotas, and easier than some of the other things in my queue, too.

I hope to work on this soonish, but we'll see.

How easy? Take a look at this commit. It's like 130-ish lines, half of which is converting a nested Go structure into nested Lua tables. For the purpose of the spam filter, we'd need a lot less conversion.

@algernon I don't mean to criticize this decision, but I think you may enjoy this related talk about "cheap complexity":

https://securityboulevard.com/2018/06/cycon-2018-thomas-dulliens-security-moores-law-and-the-anomaly-of-cheap-complexity/

@buherator You were right, I did enjoy this talk a lot! It was very educational, and gave me a few ideas how to reduce the complexity of my idea.

It didn't convince me to drop Lua, but it did reveal ways in which it could be attacked which I did not think of, and against which I can guard now.

@algernon Great to hear that! I really don't want to be that security who says "no." to everything: sometimes a full-blown embedded programming language has its place, we just have to be aware of the risks we're taking.