We have a team currently working on improving the detection and mitigation of spam. We continue to look for ways to improve the security and user experience of our product. Our product includes the Akismet Spam filter which you can read more about in our handbook: https://about.gitlab.com/handbook/support/workflows/managing.... Further, Gitlab.com includes the ability to report abuse directly to our trust & safety team here: https://about.gitlab.com/handbook/engineering/security/opera... however, the report abuse feature on self-managed reports back to the instance admin. We are also currently developing an anti-spam feature intended to further improve spam detection & mitigation. This is set to be enabled on GitLab.com within 3 months.
As mentioned above in the thread, multiple times, maybe a simpler solution to reduce spam is to remove incentives by:
- removing links (making them as plain text forcing users to copy paste them..)
- hiding links from non-registered users (plain text to non-registered users, clickable for registered users),
- blocking links from search engine crawlers (robots.txt / rel=nofollow...).
Maybe these fall in the "for each complex problem there is simple but wrong solution" but it sounds like it's worth a try.
(I already replied on a different thread but this might make more sense)
A service like Stop Forum Spam might be a solution to this. It checks for IP address and email address and gives it a value based on how likely it is assumed to be a spammer.
When they have to set up a new email account and maybe even a new IP address for every few accounts, it gets to be a lot of work soon.
That function can be called when the register form has been submitted. It will return true or false. Forget about the transient stuff, that is just WordPres caching stuff.
You don't need an API key like with Akismet. You would only need it if you want to add or remove entries from the SFS database. It really is much simpler. Ofcourse you might want to have a checkbox in the settings. But still, in an afternoon you might be able to finish this :)
That is not the core of the problem. Spammers are humans, and sometimes
they will solve recaptchas in large quantities to get their spam
through. Its about having a multipronged approach for administrators to
stay ahead of them. For some examples of free solutions see
https://www.mediawiki.org/wiki/Manual:Combating_spam. It's even possible
to connect spamassassin to forms. Gitlab needs tools and automation that
detects and rolls back spam, bans users, knobs to tune restrictions and
rate limits based on how spammers are acting. Gitlab inc just hasn't
seemed to care much to help people trying to use Gitlab and keep their software freedom.