By ‘Git instances’ they mean Gogs instances that allow open registration. I know most of the community moved from Gogs to Gitea, and then to Forgejo, but thought this was still worth noting.
Here are the steps:
- The attacker creates a standard Git repository.
- They commit a single symbolic link pointing to a sensitive target.
- Using the PutContents API, they write data to the symlink. The system follows the link and overwrites the target file outside the repository.
- By overwriting .git/config (specifically the sshCommand), the attacker can force the system to execute arbitrary commands–
amazing.
Especially since any version of Git from the last view years has a passionate hatred of symlinks for this reason, which is a bit annoying if you’ve a legit usecase. They’re either very out-of-date, or have done some very foolish customisation…
I think the ZIP standard has something similar and it causes similar problems.
It’s because of the old notion of “be generous in what you accept and strict in what you send”. I think the error is something about adding more parent directories so that part of your zip file will be extracted above the selected directory. Not all implementations of zip support this “feature”.
There are also all kinds of stupid ancient features in tar and zip from a time when hard drives were measured in megabytes or less. The latest episode of the open source security podcast talks about it.
We also have COW filesystems now. If you need large datasets in different places, used by different projects, etc, just copy them and use BTRFS or ZFS or whatever. It wont take any space and be safer. Git also has multiple ways of connecting external data artifacts. Git should by default reject symlinks.
This is sadly not easily generalizable, since a lot of people still use legacy operating systems with filesystems like NTFS, which as far as I know is not COW.
People have open registration on those things… Thats… Brave…
I have my own gitea instance in my homelab but of course its not accessable from the internet.
Well that kinda kills collaboration
Yeah. If I needed collaboration, I would just whitelist their ips or require everyone involved to use Wireguard vpn, Tailscale or other solutions that allows access without being publically exposed.
That kills collaboration from new people who just, like, discovered your project on some Lemmy thread
They can still collaborate old school way. You can publish static mirrors of git, then take email patches lol
I do the same thing. Anything I put on there isn’t something that I would share with the Internet anyway. If it was a serious project, sure. It’s just nice to have a personal git you can access over a VPN sometimes.
I can’t understand why anyone would waste time writing code that won’t be shared
Personal projects. Not everything has to be FOSS. My tiny little script to automate my lights turning green and my smart speaker playing All-Star by Smash Mouth at full volume, so I can jork it in peace? That shit doesn’t need to be public.
Home Assistant hs communities to share exactly that
My similar script has a very different goal: at midnight if someone is still up, it dims the family room light and announces on speaker”hey kids, it’s time for bed”
Yes, it needs to be public. The videos too.
Take my money.
For personal use? To automate tasks you do or solve a problem you have? Or people use git repos for notes and the like too
For personal use. As someone who has all my non-trivial creations, including dot-files and scripts I replicate between machines, in repos since CVS has a thing it’s a habit. Version control. This stuff is mostly private but not secret, why should I have it public?
Edit after spell check.
Dunno, I just don’t believe my NixOS config files are particularly valuable. What is the benefit of sharing garbage code from a novice? I’d rather share things worth sharing, that could be useful to someone else.
Don’t kink shame, man
You can git pull a repo to your machine, make your changes and then use git to submit a patch via email. Its not pretty, but it works. Hopefully federation is built soon and you will be able to submit a pull request from your own forge.
I keep mine accessible from the internet, its just more useful to me like that. I do have registration disabled though and SSO is handled by Authentik so it could be worse (my personal goal has just been to not be the easiest target, perfect security is a myth in my mind).
Theres a HUGE difference between hosting it essentially read-only to the world, vs allowing account creation, uploading, and processing unknown files by the server.
I have thought of blocking access to the commit history pages at the reverse proxy to cut off 99% of the traffic from bots. If anyone wants to look at the history, its just a git clone away.
You could also throw it behind mTLS
I could, but then I would have issues getting to it from work; from the bit I’ve read about mTLS, it’s not really indended for my use case, I think I’ll just stick with TLS.
My motto is ‘Users cause complexities and complexities cause problems’.
It is because it is the default
this is what I’m talking about when it comes to the selfhosted communities.
if you don’t know how to properly segment and vlan your network, you have no business exposing your shit to the internet.
While good, network security isnt the issue. Its running a web service with open registration allowing randos to upload content that gets processed by the server.
Throw this up on a dedicated $5 VPS and you still have a problem. The default should be manual registration by admins.
If i remember correctly on my gitea (now forgejo) the default is open registration which really shouldn’t be the case for projects that are targeted towards self hosters.
My inital install was a long time ago so I don’t remember for sure
Yeah in my project open registration is behind an option called
yes_i_am_very_very_sure_i_want_an_open_registration_server_prone_to_abuselolHonestly, this is always more effective than a comment in the config because it can get removed. All it would take is a popular guide having the config with that option on and the comment gone.
This absolutely. Anyone who actually wants open registration will be configuring their own SSO or whatever backend. The default should be safe for testing and/or hobbyists.
I’m a current gitea user… should I be moving to forgejo?
Yes, even without this current news.
Thanks! I’ll add it to the todo list.
I just did it not long a ago. Gittea -> Forgejo10 -> Forgejo11 LTS, in Docker. Surprisingly quick, painless and smooth.
(My only issue was not Forgejo, but MySQL. Because the hardware is ancient and Docker compose pulled down a new version of mysql8 at the same time as pulling forgejo. New version of mysql8 didnt support my CPU architecture. Easy fix was to change the label mysql8oraclelinux7 in Docker compose and pull that image. There is a issue with solutions in the MySQL Docker GitHub repo)
Doesn’t Forgejo support SQLite as a backend?
Yes, although MySQL/MariaDB or PostgreSQL are the more robust options.
If MySQL is more robust than SQLite of all things, something is going seriously wrong.
Then again, it’s 2025. I no longer bet on what to expect from reality. Next someone points me to a mail indicating linux kernel will move its bookkeeping to MongoDB.
To be honest I don’t remember why I set up gitea with MySQL instead of sqlite (or MariaDB), its quite a few years ago. And sqlite would probably be fine for my single-user instance
Doesn’t seem like Gitea has that issue, and just keep registrations disabled if possible and if your projects allow, avoid symlinking.
Reading between the lines I feel like when you say “Targeted towards self hosters” what you mean is “John Q Hobbyist who doesn’t know any better”
And in response to that I would contend that Gitea is not actually targeted at those folks, though they obviously use it. Gitea is FOSS but it’s still “targeted” at professionals.
deleted by creator
