@hugot @ashimokawa cool, thank you! Will add some comments in the issue tracker later today.

@topio @ashimokawa Liebe Grüße und ganz großen Dank für die Unterstützung!

@codeberg I couldn't help it, I started working on a thing that might help deal with those pesky API spammers!

Created a codeberg account in the process 😉

codeberg.org/hugot/gitea-api-p

@patchman@social.linux.pizza @af this is essentially the flow we implement right now that is not hindering spammers: create account semi-manually passing capture and activation-email, then using http API to flood with spam issue comments.

Wikipedia is getting 19 years old!

Happy Birthday!

@af registration requires a captcha already, attacks are executed via api

- Short-term, we had no suggestion for a quick implementation aside from disallowing disposable emails and tor access.

(3/3)

- Less support for disposable one-time email addresses, as a good use case is still to be reported. (Only one request via anon DM without explanation why).
- Desire for proper per-repo and user rate limits for issue and comment submission,/also implementation of reputation score (users who submitted productive content in the past are less affected by limits). Unfortunately this is a long-term project contributors still has to show up for.
(2/3)

Status report and wrap-up up of poll discussion and decision since yesterday:

- Spam attacks continue, fine-grained blocks are circumvented quickly using another anonymous email provider for registration. All attacks come via tor switching IPs every few requests.
- Many expressed sympathy to keep access via tor network open as there are valid use cases (repressive countries etc).

(1/2)

@hugot Seems this would involve significant changes within gitea. Long-term a built-in trust-scoring system will surely be great, the gitea core developers will surely like this as well?

Anybody volunteering?

@hugot This particular spammer was posting the content of random-not-so-random birdsite posts.

@utf8equalsX The traffic is coming through Tor exit nodes, we do not operate a hidden service

@utf8equalsX There are surely perfectly legitimate use cases, especially for users living in disadvantages countries. Still we need to find a mode of operation that ensures that single troublemakers cannot disrupt functionality required by other contributors.

@stevenroose @berkes one request per 5sec possibly a bit tight for interactive use, at the same time one spam issue comment every 5 seconds already quite a lot

@stevenroose @berkes Rate-limiting makes sense here, but need to check carefully that interactive use cases like GitNex client apps are not impacted.

Show more
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!