Woke up this morning to yet more Linode alerts and another failed server as a result of AI bots relentlessly scraping my #Gitea instance.

I heard about #Anubis (https://anubis.techaro.lol) when Xe Iaso (https://xeiaso.net) was on a recent episode of the #SelfHostedShow podcast and so it seemed like a great opportunity to give it a try. I don't really need "SEO" or any discoverability on Gitea, so hopefully the only downside is that new visitors need to wait a few secs before things load

Gitea v1.23.7 Released: https://github.com/go-gitea/gitea/releases/tag/v1.23.7
#linux #linuxgaming #update #foss #release #gitea #git #selfhosted

Gitea 1.23.7 is out now!

This important update includes essential fixes and improvements—upgrading ASAP is highly recommended for all users!

More details: https://blog.gitea.com/release-of-1.23.7/

Doing some research on #LLM #bot protection for our selfhosted services. We had multiple downtimes per week for last few months mostly due to crawlers DDOSing our #gitea service which brought the whole server to its knees (running more than 15 web services). It would be nice to hand out invoices for our devops work...

Anyways #askFedi what kind of protection would you recommend? We're opting for solution that's quick and easy to implement and lightweight.

Hm... so this new AI thing from @gitea ... it's definitely interesting, and many people aren't reading, again.

So, what did they do?

They basically created an API client that is usable for LLMs - meaning that LLMs can now directly interact with Gitea. It's not integrated into the server by itself, and nobody is required to use it. Basically, it's HTTP MCP. It's like an API client for a programming language. So it's not a bad thing in itself.

Also, this client by itself doesn't crawl other sites / uses data that was crawled from other sites, since it's literally just an API client.

BUT (!) you have to use an existing LLM model using a client (e.g. Cursor) to be able to use this API client. Now that's the interesting part... I don't know if there's actually a good LLM that only learned from data that it was allowed to use. This means, that Gitea kind of promotes using LLMs that crawled people's sites without their permission.

Sadly, the screenshots shown in the blog post by Gitea don't show what model they are using, so we can't tell if they are using a good or a bad model. (Though, I'm not sure if we specifically need to know that in this case.)

Anyway, I'm always happy to see people switch to @forgejo. I, personally, used it almost since I started moving away from GitHub / -Lab and I love it. Sadly, I know a few people who can't yet move to Forgejo since they're using architectures that Forgejo doesn't build for docker yet.

For those people who are still angry and "need to" be aggressive towards the devs: Calm down, maybe read my blog post that I made in collaboration with Finnley about outrage (https://steffo.blog/outrage-warps-reality/) and have a great day. Maybe go for a walk outside?

Anyway, have a lovely day!

Many universities and research institutes have their own #Gitlab or #Gitea instances, which is a good thing. But are there any plans for these instances to be federated ? It's a bit cumbersome to open a new account on a new instance every time I want to collaborate on a project. #openscience

If you, like me, are incredibly excited by this wonderful news, know that —at least for now— you can disable all this #Copilot crap by visiting https://github.com/settings/copilot and switching all the options to Disabled/Blocked. Perhaps especially the on-by-default "Allow GitHub to use my data for product improvements" one.
Thanks to #GitHub for reminding me how glad I am for #SelfHosting my own #Gitea #Git #Forge. If you're not already, maybe consider it or a (partial) move to #Codeberg too. It's great!

Anyone done a #Gitea to #Forgejo migration? Is the guide on the Forgejo site sufficient documentation?

ETA: I was one version too far to do the database compatible switchover, but it was easy enough to install, configure, and reimport my repos.

I should've known an alternative existed for #dependabot.

#renovatebot is pretty interesting. You can run fairly quickly. And it supports #gitea and #forgejo.

https://github.com/renovatebot/renovate

Hi everyone, GitNex 8.0.0 is now out with numerous new features and UI refinements.

- User activity heatmap on the profile
- Dependencies for issues and prs
- Tracked time for issues and prs
- Search within files
- Filter issues by labels
- Filter issues where I am mentioned
- and more...

It's time to update!

Release notes: https://codeberg.org/gitnex/GitNex/releases

Bericht KW11:

- MO: Urlaub
- DI: Rollout #3CX
- MI: Unternehmerfrühstück #netzwerken Diverses #vpn #Updates
- DO: Diverses #OPNsense Regeln angepasst. #haproxy mit #acme Umstellung von #NAT. Netzwerkberatung
- FR: Bürotag. #ActiveDirectory Fehlersuche. #OPNsense Firewall im HA-Cluster ausgerollt

Highlight: #OPNsense HA-Cluster sind ein Traum. #Gitea Projektverwaltung ist noch träumiger :D

For some reason I can't SSH from my laptop to my #Gitea server via its public interface. It just keeps timing out. It's only the laptop having this issue; my tablet and phone are doing this just fine. I was finally able to push my commits by sending them directly over the LAN instead. I've tried resetting the VPN on the laptop, but it's still not working normally.

I am officially confused.

Gitea v1.23.5 Released: https://github.com/go-gitea/gitea/releases/tag/v1.23.5
#linux #foss #release #git #gitea #selfhosted

If you run a #Drone CI server, set DRONE_REGISTRATION_CLOSED=true (and manually create users only when you really really trust someone).

The CPU on my CI/CD server suddenly spiked to 100% today.

A closer look found some users who had registered on git.platypush.tech and on the CI/CD server and created a repo with a .drone.yml, a .gitlab-ci.yml and some scripts with base64-encoded commands.

The repo also contains a deepCC.ipynb Jupyter notebook that downloads some training data from S3 and uses Tensorflow to train a model, and then uses the deepCC binary to do something with that model.

The repository also has a configure script with base64-encoded commands that seem to configure a miner (the wallet ID is R9WpFbvkb6dep6bfLdbpcyz3LpMeikUL6W and the coin is VRSC, if anyone is interested in investigating further).

The deepCC binary is itself quite big (~50 MB), and a look at the setup script reveals that it’s actually a .tar.gz archive with a larger binary inside.

A quick run of strings on the binary confirms that it’s actually a miner - it connects to eu1-etc.ethermine.org and it also has a bunch of CUDA bindings to run on GPUs.

I still don’t get what’s the point of the Jupyter notebook that trains a model and passes it to this miner, but if you feared the day of the arrival of the zombie Docker containers that exhaust system resources by mining cryptocrap AND training AI models, well, I’m afraid to inform you that that day has come.

If you are a #Gitea / #Forgejo admin, take a look at the users and repos created in the past couple of weeks. Check in particular if any recently registered users have created a repo named deepcc-v.

The most likely authors are users named farzanfarid16 and zurizoey0.

A quick search confirms that both these users are registered on #Gitea too and have already created the incriminated repo:

• https://gitea.com/farzanfarid16/deepcc-v
• https://gitea.com/zurizoey0/deepcc-v

And if you are a Drone CI or #Gitlab admin, check if any of these users have also started CI/CD pipelines connected to that repo.

For now, disabling the execution of CI/CD pipelines unless a user has been explicitly authorized is the best idea that comes to my mind.