Hacker News

Lots of Unit 8200 peeps.

I'm not there, but we use it at our place. It triggers on entirely innocent things I do.

And yet when I do something a bit dodgy (like query a DC with a cli, and reset credentials) it's silent...

Oh Bobby Tables, your mom was quite clever.

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.

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.

I guess I woukd say youre fortunate to have not worked in a "we cannot use github.com because we take security very seriously" environment. Because always tells me you'll be running a on prem product that might get updated once a year.

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 ...

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.

It throws a wrench into the argument of not publishing your source because AI will more easily compromise the code.

Another data point against doing security through obscurity.

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).

We moved from github to a self-hosted forgejo instance about 6 months ago, works like a charm. Still can't belive how snappy forgejo is / laggy github has become

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.

Self hosted gitlab behind a VPN.

The all-in-docker image and a couple of gitlab runners is all small to medium sized teams need. (Don't overcomplicate it with the kubernetes version unless you really need it)

GitLab ?

just git

.... 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.

Transformers were literally designed for translation.

As we have known for a while, they ended up being really good at translating source to source or text to source. It shouldn't be too surprising they are also really good at understanding the asm version too.

Doesn't make it any less impressive, but maybe less surprising.

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.

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.

https://news.ycombinator.com/newsguidelines.html

Only if they take Skype off the syllabus first.