If you could only choose from github, gitlab and atlassan then I suppose.. But really anything newer that stays in existance has to be focused on quality from early enough to not be defined by path dependence problems and bad choices like those 3.
chucky_z · 2026-04-28 18:01:47 UTC
.... git?
replace it with git.
if you want a whole ui you can use something like forgejo which has far fewer features likely leading to less issues.
latchkey · 2026-04-28 18:05:06 UTC
i want what github offers.
heliumtera · 2026-04-28 18:07:12 UTC
Enjoy your experience, there will certainly be no end to it.
Just be careful your patronage doesn't lead to a sunk cost fallacy---a middle manager might just be betting on it
latchkey · 2026-04-28 19:07:13 UTC
I have no ingrained loyalty, I just haven't found something better.
debugnik · 2026-04-28 18:21:33 UTC
You probably meant Forgejo. Codeberg is a Forgejo instance exclusive for FOSS projects.
Caligatio · 2026-04-28 18:24:53 UTC
I am personally now drawing a clear delineation between projects for my internal consumption (e.g. ansible scripts) and projects that have potential use for the general populace. For the prior, I now host a private Forgejo instance. For the latter, I'll put it on GitHub but mirror it to my Forgejo instance.
I was pleasantly shocked that Forgejo is literally a single binary with a relatively easy config. All my internal services reference my Forgejo instance so, if I need to bail on GitHub, it's low friction for me.
skrrtww · 2026-04-28 18:33:11 UTC
A "reasonable" answer is probably a primary self-hosted Forgejo instance as the canonical forge, while using GitHub as a mirror solely to take advantage of its free CI, while that lasts, while hosting secrets with a dedicated secret-hosting provider (I don't know what the provider du jour for this is these days).
latchkey · 2026-04-28 18:39:52 UTC
Replace a whole 24/7 team of devops people with myself?
As much as I'd like to believe that I'm worthy, I'm not.
skrrtww · 2026-04-28 18:45:06 UTC
If the primary forge's only job is to host the actual Git infrastructure (the code, the MRs, the issues, maybe a wiki), it's a lot more simple than GitHub, and probably more within the scope of what people can reasonably administer themselves.
latchkey · 2026-04-28 19:10:46 UTC
I hosted the first "java.apache.org". I was an early employee at CollabNet, and in the first discussions around starting subversion. I worked on Cloud Foundry.
This stuff isn't easy and I'm more than happy letting someone else do it at the expense of some downtime.
embedding-shape · 2026-04-28 18:57:52 UTC
> solely to take advantage of its free CI, while that lasts
Eh, if you want to be able to continue working, deploy and what not as normal during weekdays, I'd suggest also moving to Forgejo Actions if you're moving anyways. Not 100% compatible, but more or less the same, and even paying the same but with dedicated hardware you'd get way faster runners.
skrrtww · 2026-04-28 20:40:15 UTC
For companies with resources for infrastructure, sure.
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
willworktill4pm · 2026-04-28 17:24:50 UTC
GitHub case will be thought in schools how to screw up almost monopolistic position in the market in couple years. This is beyond bonkers.
hnlmorg · 2026-04-28 18:25:38 UTC
Only if they take Skype off the syllabus first.
xaxfixho · 2026-04-28 19:07:57 UTC
private equity: hold my beer!
bananapub · 2026-04-28 17:46:22 UTC
> April 28, 2026
> GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable
88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems ... bad.
pixl97 · 2026-04-28 17:57:01 UTC
Question is how fragile the upgrade process is in large installations. In other enterprise software messing around with large amounts of data I've seen the smallest things break the install and leaving the OPs team rolling back. Was like SharePoint in the past, you were rolling a dice when upgrading it.
chucky_z · 2026-04-28 18:00:56 UTC
It's incredibly fragile. It breaks a vast majority of the time and takes multiple rounds of support on-call to upgrade typically.
formerly_proven · 2026-04-28 18:49:17 UTC
Unsurprising for a fourth tier on-prem created by cutting a continuously deployed application into releases.
bombcar · 2026-04-28 18:38:01 UTC
If you're in the enterprise you can update something outside of the normal schedule and guarantee blow up everything (and be blamed) or you can stick with the schedule and hope for the best.
Guess which is usually picked ...
brianmcnulty · 2026-04-28 18:45:52 UTC
I assume a fair amount of these on-prem customers restrict access to their GHES instance to be behind corporate VPN or something similar and are planning a date to upgrade their instance that won't affect operations.
Any public instance should update immediately though, it's not very hard to put together how to repro the vulnerability on your own from what they provide in the article and the fact that GitHub Enterprise source is publicly available.
semiquaver · 2026-04-28 19:59:03 UTC
GHES is essentially unmaintained (perhaps “on life support” would be more charitable since they are certainly accepting payment for it) and has been so for about a decade. It requires a multi-hour downtime to apply even a patch-level release. They do not have any supported mechanism for HA upgrades. So even the most conscientious GHES customers lag the latest version because they can’t afford the downtime.
They are constantly telling all their GHES customers who complain about the severe flaws with the self-hosted appliance product to move to GitHub Enterprise Cloud, which is just regular GitHub.com, but who in their right mind would make that move nowadays??? At least GHES stays up during the daily github.com outages.
baby_souffle · 2026-04-28 20:05:41 UTC
You can at least schedule the updates.
It's still a pretty annoying process, though.
semiquaver · 2026-04-28 20:08:32 UTC
Until GHES can do zero-downtime upgrades nothing will get better. Not on their roadmap because as far as I’m aware the GHES team doesn’t actually exist or is entirely focused on KLTO. It’s a dead product that they wish didn’t exist.
everfrustrated · 2026-04-28 21:00:51 UTC
Pretty sure GitHub Enterprise Cloud is just Github hosting their enterprise server for you on Azure so you don't have to do the patching yourself.
WASDx · 2026-04-28 18:55:09 UTC
I was impressed enough by AI finding vulnerabilities in source code, but doing it in binary executables is just amazing. This has so much potential, good and bad.
And yet another lesson to not treat data as instructions. Sanitize all user input!
jcims · 2026-04-28 19:18:28 UTC
Anyone in here work at Wiz? Seem like they do pretty good work. Tool itself has survived extreme growth/feature bloat and still does pretty well. Security team has found some really cool stuff.
halger · 2026-04-28 19:28:35 UTC
Woah I wonder if they can tell if this has been exploited or not
semiquaver · 2026-04-28 19:50:08 UTC
My read is that this vulnerability is exploitable by an anonymous user. They absolutely have HTTP/gitprotocol logs that would indicate whether this was exploited but if it was, they won’t have logging about what actually got accessed and who did it, since the exploit was capable of standalone execution on the git servers, which would by definition be capable of evading any logging.
formerly_proven · 2026-04-28 19:53:37 UTC
This is just such an amateur hour vulnerability. Gluing strings together with no regard to what might be in them and then parsing them later...
edit: I didn't mean it as a put-down of either the article or how they found the vulnerability, but it wasn't a constructive comment either way.
dang · 2026-04-28 20:02:28 UTC
It's good to add information about what the vulnerability actually was, but please don't do it in the key of putdown. We're trying for something else here.
They hint at their AI-augmented reversing methodology, which demonstrates one of the core strengths of current LLM agents. These models, trained extensively on code, can immensely speed up the process of understanding complex system internals.
Security research historically has two difficult components that build on one another:
1. Understanding complex system internals: uncovering the inner workings hidden by abstractions or interfaces
2. Finding vulnerabilities in these uncovered mechanisms
Sometimes both steps are equally hard. But often, finding the vulnerability is trivial once the real mechanisms are uncovered, rather than relying on assumptions about inner workings.
CVE-2026-3854 is a case where the vulnerability is not plainly obvious after understanding the internals. Still, I am confident that this command injection would have been found quickly had it been exposed to a more traditional or accessible attack surface.
Comments
If GH is getting RCE's this late in the game who wants to take the chance something else won't?
https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
replace it with git.
if you want a whole ui you can use something like forgejo which has far fewer features likely leading to less issues.
updated: changed the date to 2008.
my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst
I was pleasantly shocked that Forgejo is literally a single binary with a relatively easy config. All my internal services reference my Forgejo instance so, if I need to bail on GitHub, it's low friction for me.
As much as I'd like to believe that I'm worthy, I'm not.
This stuff isn't easy and I'm more than happy letting someone else do it at the expense of some downtime.
Eh, if you want to be able to continue working, deploy and what not as normal during weekdays, I'd suggest also moving to Forgejo Actions if you're moving anyways. Not 100% compatible, but more or less the same, and even paying the same but with dedicated hardware you'd get way faster runners.
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
> GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable
> Upgrade to GHES version 3.19.3 or later
https://docs.github.com/en/enterprise-server@3.19/admin/rele... :
> Enterprise Server 3.19.3 - March 10, 2026
88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems ... bad.
Guess which is usually picked ...
Any public instance should update immediately though, it's not very hard to put together how to repro the vulnerability on your own from what they provide in the article and the fact that GitHub Enterprise source is publicly available.
They are constantly telling all their GHES customers who complain about the severe flaws with the self-hosted appliance product to move to GitHub Enterprise Cloud, which is just regular GitHub.com, but who in their right mind would make that move nowadays??? At least GHES stays up during the daily github.com outages.
It's still a pretty annoying process, though.
And yet another lesson to not treat data as instructions. Sanitize all user input!
edit: I didn't mean it as a put-down of either the article or how they found the vulnerability, but it wasn't a constructive comment either way.
https://news.ycombinator.com/newsguidelines.html
Security research historically has two difficult components that build on one another: 1. Understanding complex system internals: uncovering the inner workings hidden by abstractions or interfaces 2. Finding vulnerabilities in these uncovered mechanisms
Sometimes both steps are equally hard. But often, finding the vulnerability is trivial once the real mechanisms are uncovered, rather than relying on assumptions about inner workings.
CVE-2026-3854 is a case where the vulnerability is not plainly obvious after understanding the internals. Still, I am confident that this command injection would have been found quickly had it been exposed to a more traditional or accessible attack surface.