GitLab is actually pretty good: the UI is nice, the feature set is pretty complete and GitLab CI is still one of the best CI solutions that i've used and probably a noticeable step up from Jenkins, or at least the Jenkins instances that i've seen, but self-hosting it and keeping it up to date certainly takes a bit of care, especially if you ever want to have it be publicly available.
That's not to say that Gitea or any other piece of software couldn't have similar vulnerabilities, but rather that GitLab is a pretty large and complex piece of software that's also moving ahead rapidly, so situations like this are inevitable (also things like the EXIF vulnerability a while back https://gitlab.com/gitlab-org/gitlab/-/issues/327121). Perhaps even something as simple as basicauth in front of it can be helpful for cases like this (or just making things available only through a VPN, though that's likely to be too limiting in some cases, e.g. non-enterprise settings).
Edit: Actually, here's a question for the lovely people here: suppose that you want to self-host a platform with a web UI for working more easily with Git repos, something like GitHub, GitLab or other platforms like that, to collaborate on a project with some friends and/or like-minded strangers. What do you, a single person with a VPS and a bit of spare time pick for the most successful outcome? Or is the only viable advice nowadays: "Don't. Just use the cloud."?
Gitea is prob the best pick if you fancy a github-a-like. Hopefully we soon have forgefed/AP federation, to facilitate collaboration across servers. The intention is to make it a standard protocol for forges to share not just code but also the coordination/social parts, so a server can choose to allow outside contribution without registering or e-mail.
As soon as you get a Postgres server up and have some flow to keep your infra in source control (ansible+docker-compose/systemd goes a long way; they're a sane starting point for the unopionated mostly because of popularity), setting up new services is pretty straight-forward.
I did use nexus at work but tbh the official docker-registry container and a static webserver have proven sufficient for personal use.
> Or is the only viable advice nowadays: "Don't. Just use the cloud."?
For the people who really can't or won't self-host, I'd suggest at least looking at smaller providers rather than defaulting to big tech for everything.
Gitea + Nexus + Drone CI is what I've been using for a while and I really like it. I dumped GitLab after it became obvious they have no interest in serving the low end (ie: small users). I have no regrets. Gitea is a much better fit for me.
Maybe I'm bias because I've become accustomed to Gitea, but I really feel like Gitea augments my workflow while GitLab and GitHub are trying to usurp my workflow. I use GitHub, but only for push mirroring when I want to use something like Cloudflare Pages / Functions that do GitOps style managed deployment.
As for an extra layer of auth, I think Cloudflare Access makes a lot of sense for small users. Put everything behind Cloudflare, use split horizon DNS for LAN access, and rely on Cloudflare to pre-auth all users before they can connect via the internet.
It's surprisingly easy and efficient to run a Gitea instance behind a reverse proxy (Nginx et. al) plugged into Let's Encrypt. The built in sqlite3 DB method is plenty capable and snappy for a dozen projects and small team of people, it runs comfortably on the typical $5 cloud server and it offers a lot of capabilities (to the users and the Admin). Hobbyist groups like Disroot and non-profits like Codeberg are using it with much success, many folks find it easy to run their own personal instance within a few hours. Plenty of people share their build recipes online to just "clone and go" to DIY.
It is most certainly a nice project and i'm all for alternatives to Git, but for many people having to give up their current tooling (e.g. IDE integrations, specific tools for graphical graphs, interactive staging of chunks, rebasing etc.) would probably be a non starter, since it's another source control system entirely, instead of a front-end/enhancement of what Git provides (e.g. ticketing, wikis, merge/pull request discussions, CI etc.).
Here's hoping that Fossil has a nice future ahead of it, there is certainly a number of projects that would benefit from it's relative simplicity when compared to Git!
There was some muttering on the fossil site somewhere about supporting git format. Darcs was another thing like that, which was superior to git in most ways I can think of, while fossil has an anti-rebasing ideology that makes it unacceptable for certain types of git workflow. I don't know how that can be resolved while switching to git format. I do like integrating issue tracking with source control.
Unfortunately darcs suffered from the patch-of-doom problem, where if you were unlucky an exponentiation merge would kill all performance of your repository.
The darcs FAQ from 2012 reports it as still unfixed:
(Yes this was real, and yes we hit it. I liked the patch-centric darcs approach, but that was enough to make us migration to mercurial, then later git.)
The IDE integrations bit is the most difficult thing for me; there was a fossil plugin for Jetbrains IDEs/IntelliJ, but it stopped being maintained, I maintained it a bit, but a large breaking change meant I didn't have enough time to keep it up, so I had to migrate away. I love fossil, but some things are difficult without a community around it developing the tools for it.
It's not for the general mass to say the least. You're better off using other focused products for each components than something that does everything in average ways.
The visual looks like they combined components from 20 years ago.
I use it every day for personal projects. Since I’ve been writing code for more than 20 years, the aesthetics aren’t as relevant to me. It’s a useful tool that works quite well. It’s not trying to win this year’s design competition.
I really like that Gitea is operationally simple and can run on a potato. If your team's fairly small, you can use SQLite to make it even simpler. GitLab's way, way too heavy.
By far the easiest method, if you mostly trust your friends, is to forego the web UI and just use a directory on an SSH server. Do `mkdir project.git && cd project.git && git init --bare` and throw everybody's SSH keys into authorized_keys on the server, `git remote add origin user@server:project.git` on the client. The problems with this are that there's no privilege separation, i.e. everyone can do anything, there's no audit logs, and as mentioned previously there's no web UI. If everyone is actually expected to have a local copy of the repository, though, I don't see this as a huge issue. Issue tracking can be handled by a TODO file in the same or a separate repository.
I find self-hosting GitLab reasonably enjoyable. I use the Docker image (which contains the omnibus installation). It takes a ridiculous time to boot but I can only remember one time when upgrading wasn't as simple as pulling the new version and re-creating the container. Don't remember what went wrong though.
It's login-only, there's no other users, so I'm not too worried about security.
I've had several upgrade issues. Once several configuration settings were deprecated then removed... Silently. It was difficult to discover why it would no longer start. Another time a bunch of repositories only partially migrated, and appeared empty on clone.
Mostly it's the frequency of updates that's a pain, there are enough critical vulnerabilities that you have to stay on top of it.
I am the dog lying on a nail and occasionally whimpering at the moment though.
GitLab is a prime example of "do many things and do them averagely". Sure it got many features but there are bugs and each feature isn't as polished as other isolated apps and it takes huge resource.
How it turned out to be a unicorn, I guess good sales and not by the technical advantage.
If you're self-hosting gitlab-ce (which should really be open to internal traffic only) and want one more layer of protection from all this stuff, it's easy to throw it behind http basic auth. In your gitlab.rb:
A more standard way is to use `auth_request`, which passes every incoming request to some auth server to get a yes/no response. And this service can be as simple or complicated as you'd like.
FYI that Gitlab rotates their package signing GPG key every two years and default yum-cron won't auto-update their packages until the new key is manually approved.
If you're going to hardcode a password like this (and I think this is one of the rare situations where it could actually make sense to do it) you need to also ensure that this hardcoded password:
From what I gathered, it was used as a placeholder for user accounts that were created via federated login. So the user would never actually be logging in to Gitlab directly with a password.
