Rendered at 23:21:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
JLO64 23 hours ago [-]
> Upgrading to GitLab 19.3.6 on October 22 didn’t fix the vulnerability. The fix isn’t in GitLab’s own code but in a patch to Ruby, which GitLab applies only in its official packages. Our image used standard Ruby, so it didn’t get the patch.
> The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab.
I feel like this era of constant exploits/patches is really bad for those who build from source or make their own images vs those who rely on provided images and upgrade them often. I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting...
Gigachad 22 hours ago [-]
At this point if you are self hosting you should have everything behind a VPN. Only companies with their own security and development teams should be putting things on the public internet.
tallanvor 11 hours ago [-]
It wasn't long ago that companies like Google were advocating for zero trust networks that avoid the need for VPNs!
Zero trust is more like you need strong authentication like FIDO on the webapp even if it's behind the VPN, not that you get rid of defense in depth.
ifwinterco 8 hours ago [-]
Zero trust ≠ publicly accessible.
And zero trust makes sense, once one service behind a VPN is compromised attackers can potentially move laterally, zero trust mitigates that
theamk 10 hours ago [-]
that works too
For personal services, even something as simple as HTTP basic auth on the webserver dramatically reduces the attack surface by blocking all probers and drive-by attacks.
jamesfinlayson 22 hours ago [-]
Gosh I'm at a big company and I'm pretty sure all the self-hosted tools are only accessible through VPN-like tech anyway. The only truly public stuff is Jira, Confluence (which I assume it more to do with Atlassian's pricing of self-hosted) and Sharepoint.
Operyl 22 hours ago [-]
Atlassian products (Jira Server) are no longer supported, and their more Enterprise offering dies in 2029, so everything is ending up in their cloud now yeah.
wtch98 10 hours ago [-]
We've just moved from on-prem (protected by MTLS) to on-cloud because of this. I now know why everyone hates jira. The cloud version is so much worse
FuriouslyAdrift 8 hours ago [-]
If you're a Microsoft shop, you can put just about anything behind Microsoft Entra Application Proxy (and also support SSO).
Or I can (and do) use something good. That doesn't change the fact atlasian no longer support on prem jira.
egeozcan 21 hours ago [-]
I know a lot of companies vibe-coding alternatives. I'm not an expert but it's perhaps even illegal for most European companies to migrate any customer data to Atlassian servers.
StableAlkyne 18 hours ago [-]
This is something I keep struggling with.
If someone wants to vibe code an alternative to a SaaS tool, my gut feeling is "no, this is bad and it will blow up" as vibe-coded projects tend to do.
But then the alternative is often paying $X million per year for licenses to a half-assed program that hasn't had a UI update since 2005.
I just don't have a good argument on why they shouldn't when the outcome will be just as dogshit, only cheaper and flashier.
ozim 17 hours ago [-]
They just started updating the UI and I am pissed off.
I don’t want them to change UI. I have plenty of work to do and have plenty of other tools that I use daily.
I have my workflows, I am swamped with work and now I have to change my workflows because someone changed options in UI where ones that O used are not there anymore.
IlanGR 13 hours ago [-]
I think there's ways to have a solid app by giving ai precise instruction about the architecture it has to follow. Especially by configuring read-only agent for security and quality and builder agents for everything else. It isn't perfect and I wouldn't do critical apps for a company with it but it's solid enough to replace a SaaS tool in my opinion. I think the real subject is wether this vibe-coder knows he'll have to maintain his app...
unrented7977 7 hours ago [-]
I'd pay embarrassing amounts of money for applications which do not get biweekly UI overhauls.
I'm still using the 2024 version of JetBrains IDEs because the UI hadn't changed in over ten years. I quit paying JetBrains when they ripped out the perfectly functional UI and replaced it with a VSCode reskin.
Please, for the love of god, give me software with a consistent UI.
gokulravi992 17 hours ago [-]
The argument I'd make isn't about UI or features, it's about who owns security afterwards. The vendor has people whose whole job is patching things like this Ruby regex issue. The internal vibe-coded Jira usually has nobody, and the bugs that bite are boring ones, like a project page that loads for anyone who guesses the ID.
If they go ahead anyway, the ask is just that someone actually owns it after launch, not only builds it.
ozim 17 hours ago [-]
Atlassian migrated EU data to EU based servers. I still had to click approve but they did that for me.
egeozcan 15 hours ago [-]
Atlassian is a US-parented company and this means that CLOUD act can affect it. Even this only can make it unsuitable. Then there are questions to data-in-transit. Also nothing is legally tested. Vibe-coding an alternative is much safer if you have sensitive customer data (even simple support tickets).
input_sh 15 hours ago [-]
Not that this matters in terms of the CLOUD Act, but it's actually an Australian company based in Sydney.
egeozcan 15 hours ago [-]
As far as I know the ultimate (as in, when you follow the chain) holding company is from Delaware.
UqWBcuFx6NV4r 13 hours ago [-]
Yep.
ozim 9 hours ago [-]
Going with this idea further basically all data goes via Microsoft one way or another.
usrnm 15 hours ago [-]
The location of the servers matters only if you're trying to prevent physical access, for anything else it's completely irrelevant
griffiths 21 hours ago [-]
Can you give more information on "illegal for most European companies" part? Asking for a EU company using Jira :)
Sebguer 20 hours ago [-]
This person is just posting absolutely baseless claims, as if Atlassian, a company that basically exists purely on the back of B2B SaaS sales, has not considered EU data residency requirements in their core product offering: https://www.atlassian.com/software/data-residency
dijit 15 hours ago [-]
FWIW nearly every SaaS or IaaS is making bold claims about supporting data sovereignty, but unless it has been challenged in court I wouldn’t put much stock into it.
The fact that Jira/Confluence are being processed by their LLMs puts them in direct legal conflict with several statutes in the EU, its a matter of time for them to get hit by this and I’m betting that they think the fine will be lower than the revenue they acquire for doing it- and they’re hoping they don’t get hit at all.
This seems to be the common case for a lot of the non-EU tech companies, and it seems to be working.
Oracle is currently the market leader in “sovereign” compute for EU governments for example, as ironic as that is.
egeozcan 15 hours ago [-]
> This person is just posting absolutely baseless claims
You don't need to be so hostile. I know about the EU requirements but many EU companies have sensitive data on hosted JIRA / Confluence that simply cannot be in the possession of a non-European company. I know because I'm working for one. I cannot even remote-work from outside Europe. Some stuff cannot even leave the VPN. There's also the CLOUD act.
jamesfinlayson 19 hours ago [-]
Yeah I thought Jira at least was all built on AWS these days. I've never set up a Jira Cloud instance but I'd be surprised if you don't chose where your data lives.
kenniskrag 17 hours ago [-]
In short gdpr compliant means you can configure it but it must not be compliant by default and also there is no guarantee.
They are constantly changing their software and settings. More than once they believed that something is legal but can be risky for the atlassian customer.
For example training AI on metadata which they believe are anonymized but are maybe not enough changed.
Training data or metadata permisson can not be configured on all subscriptions. But as a data processor they must follow the contract otherwise they become data controller.
Also there are risks associated with privacy data framework, cloud act etc. to be non compliant just by data transfers to other countries.
> We have not requested CVE identifiers in Ruby for these fixes, at least for now.
> Ruby has generally considered it unsafe to compile and use a regular expression created from untrusted input. We stated this in the advisory for CVE-2022-28738, where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment. We did the same for CVE-2024-27282.
couchand 22 hours ago [-]
It's a Bad Idea (TM) to compile a regular expression from an untrusted input.
Despite what anyone would try to sell you, a regular expression is a programming language. It's Always A Bad Idea (TM) to compile untrusted input into any kind of programming language. Don't string concatenate SQL queries, eval is evil, it's all the same idea.
Blackthorn 20 hours ago [-]
A regex might be a programming language, a proper regular expression (which there are libraries for, like Google RE2) is just a regular language and I don't think you can even charitably call that a programming language.
luhn 7 hours ago [-]
What's the difference between regex and regular expression? I always understood the former to be an abbreviation for the latter.
Despite this Ruby should have requested CVE numbers. They created a patch that was available to install and prevented this attack. CVE numbers would have triggered automations to update Ruby in everyones systems.
rendaw 17 hours ago [-]
Why is it a bad idea, for either of those? Fundamentally?
quibono 14 hours ago [-]
Yes, after all there is no distinction between data and code since they're the same thing when it comes down to the bytes in memory.
milkshakes 18 hours ago [-]
> It's a Bad Idea (TM) to compile a regular expression from an untrusted input.
i agree with you!
nevertheless,
> where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment
not sure what sort of comprehensive assessment is still called for at this point?
weinzierl 22 hours ago [-]
At the beginning of the industrialization there were many accidents with steam boilers.
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
bombcar 21 hours ago [-]
What’s interesting with steam boilers and other types of OSHA related injuries is that it’s not enough that the person who’s doing the stupid thing dies: you have to enforce it even more and even higher. People won’t value their life.
cowlevel 9 hours ago [-]
Usually they have a choice between risking their life in a boiler explosion or risking their life in homelessness.
alansaber 7 hours ago [-]
This seems much more fundamental, less social, though.
esseph 20 hours ago [-]
> This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
Security is always reactive by its very nature. You can do proactive things, but you will always be reactive to novel attacks.
Expect everything to have various levels of rolling upgrades, and soon. That's a lot of work.
weinzierl 18 hours ago [-]
We don't do rolling upgrades on steam boilers nor do we do it on our door locks. Nothing is perfect, we just need good enough and we are currently far away from good at all.
When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.
It's not that it can't be done.
It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.
cowlevel 9 hours ago [-]
Most door locks are easy to pick btw. They're not protecting you with technical excellence, they're protecting you by making the thief spend a little time so the neighbours might see him.
esseph 8 hours ago [-]
> but modern languages, tooling and formal methods will hopefully mitigate that enough.
No, they won't :) This is the world now.
edoceo 23 hours ago [-]
The PHP2Shell one was both lucrative and exhausting. I maintain a bunch of legacy PHP apps.
jayd16 21 hours ago [-]
Dynamically linked dependencies? CI and semver aware automatic dependency tracking? Automatic updates pointed at personal app depots?
0x1F8B 21 hours ago [-]
> I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting
The future is near constant burning of tokens in your software factory to do this automatically. The labs create the increase in demand for their own product.
pixl97 21 hours ago [-]
Turns out building the world on an infrastructure of lies has finally caught up with us.
The way LLMs are developed now is but one possible future we could have experienced. Imagine the future where the LLMs were built by a few governments with black budgets and hidden until a war or some other large event broke out. Then suddenly most of the computers and digital infrastructure shits itself as everything goes wonky.
At least this way we get to see that a shared global infrastructure built on the idea that security is someone else's problem was a really bad idea and we might have enough time to fix it or pull enough plugs we don't go back to the dark age.
Gigachad 21 hours ago [-]
That's a for now problem. The future is probably less software surface area exposed to the internet, the removal of unsafe languages from software exposed to the network, services like Cloudflare deploying firewalls to detect exploit attempts, and services that can keep a live database of currently active bots and residential proxies to IP block them.
Alongside the current scanning and patching of software.
0x1F8B 21 hours ago [-]
I don't disagree. Also probably more logs and more metrics since LLMs can scale instrumentation, signals and auditing far beyond what humans could ever process, which in turn, more tokens. Probably larger Datadog bills too.
esseph 20 hours ago [-]
> Probably larger Datadog bills too.
I don't think that lasts, I've seen at least 5 viable replacements now. All internal projects at major US companies.
devrwoody 13 hours ago [-]
Us too. My new company find themselves paying more for DD than hosting resources they monitor. That’s ending soon!
rconti 22 hours ago [-]
The world has changed but 15 years ago we thought it was utterly insane to just pull whatever $latest from $internetsite.probablytrusted.org as part of your build and deployment process.
Melatonic 15 hours ago [-]
Still not insane
esseph 23 hours ago [-]
It's not maintainable unless you autobuild, and yes, upgrade treadmill.
Gigachad 22 hours ago [-]
The patch for Ruby came out 6 days ago. Most Rails apps do not use the Ruby from the package manager but have a hardcoded version in the repo. So unless you have developers releasing a PR to update ruby the moment it comes out, you aren't safe.
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
edoceo 22 hours ago [-]
True for many others right? PHP, Python, JS, Lua..what if some finds an old exploit in Perl, oh heck.
awesome_dude 22 hours ago [-]
> build from source or make their own images vs those who rely on provided images and upgrade them often.
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
cpuguy83 11 hours ago [-]
I'm curious what you mean about vendoring.
In go, vendoring dependencies just copies the deps out of the module system into the local tree and it's managed the same as not vendoring. It won't even build of the go.mod has changed without also updating the vendor tree.
awesome_dude 6 hours ago [-]
Right - a copy is a cache, and you have to manage that; when to update it, when vulnerabilities are discovered in the deps you have copied, it's up to you to change the version in your cache.
IlanGR 9 hours ago [-]
[dead]
cowlevel 22 hours ago [-]
The bug is integer overflow in a random C data-processing library (specifically regexes) leading to RCE.
Who else is tired of C libraries since this week?
Gigachad 22 hours ago [-]
I've been calling this out for forever now and have been repeatedly told that actually, competent devs with C are fine and the C software we use has been battle tested so it's largely secure.
And now we are seeing that was all untrue.
cristoperb 22 hours ago [-]
now it's even more battle tested!
angry_octet 10 hours ago [-]
"AI Battle Tested!"
awesome_dude 20 hours ago [-]
Let's rewrite everything - said every 15 minutes by every new developer with a new toy.
How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.
Gigachad 20 hours ago [-]
This was hardly a convincing argument before the current CVE explosion. By now C needs to be dead and buried for network accessible code.
How is this constructive when you're offering nothing to construct? Just saying not to be surprised.
awesome_dude 18 hours ago [-]
You really think it wasn't constructive - is that a you bias or a me bias?
dvdkon 14 hours ago [-]
Sorry, it's you. You basically told people that they should expect bugs in old code and shot down the proposed fix without offering any other solution; that's non-constructive by definition.
cowlevel 10 hours ago [-]
tbf "rewrite everything" isn't a very constructive statement either.
grumbelbart2 9 hours ago [-]
Which options are there, really? There is re-write, fixing, and mitigation.
We have a lot of legacy code that probably contains many bugs that could be exploited.
We could either stop using that legacy code, i.e. re-write and move to a newer library / package. Or fix the old code.
I now believe that "fixing" the code is actually in reach for an organization such as Google, which has deep pockets, frontier AI models, and a history of working on open source. Spend a few billions to walk through every package that runs on a common Linux installation, find potential issues and robustify the code.
awesome_dude 6 hours ago [-]
The code is FOSS, it's been sitting there in the open for its lifetime available for anyone to inspect, discover bugs, and fix (patch or rewrite)
The inspection/discovery part is what has accelerated; the fix, patch or rewrite, has not.
People smugly yelling on the internet to rewrite because they have a new toy isn't constructive - why aren't they out there doing it already?
grg0 21 hours ago [-]
And how does Rust help? As far as I know, an integer overflow in Rust panics in debug but just wraps in release (a bad choice in my opinion). Would it help specifically in the code execution part of the exploit?
jeroenhd 14 hours ago [-]
The integer overflow issue is only part of the problem. There are a couple underlying issues that make this exploit feasible: certain regexes produce extremely long bytecode, the integer overflow issue, and finally, a double free.
Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).
jooops1 21 hours ago [-]
The key difference is even If an Integer overflows in Rust It still doesn't violate memory safety in safe Rust and therefore doesn't lead to exploitation.
dgrunwald 15 hours ago [-]
Depends on what kind of exploitation you're talking about -- integer overflows can still cause out of memory conditions and crash the program, which is a denial-of-service vulnerability when talking about webapps.
But yes, memory-save languages like Rust are a massive help protecting against remote code execution. (unless said memory-safe language introduces its own category of RCE vulnerabilities, e.g. deserialization in Java)
Fordec 19 hours ago [-]
[profile.release]
overflow-checks = true
jeroenhd 14 hours ago [-]
Xe Iaso's blog posts poking fun at C(++) titled '"No way to prevent this" say users of only language where this regularly happens' has been quite busy this month.
Getting rid of C isn't the holy grail it might appear to be (Ubuntu has been working hard at rewriting sudo and coreutils in Rust and they have had plenty of bugs in the process), but I do hope the C projects will preemptively start fuzzing/running fil-C/invent new safety mechanisms for old code.
awesome_dude 2 hours ago [-]
> but I do hope the C projects will preemptively start fuzzing
One of the points I wish more people understood about fuzzing is what it is doing is grabbing a random selection of all the possible inputs and running them through the function (Yes the fuzzer can be made to target/exercise different branches in the code, but it's still doing that with a random selection of the possible inputs that will exercise said piece of code).
Fuzzers miss bugs, because the full corpus of possible inputs is impossible to permutate through every function.
But the advantage of fuzzers is that they choose inputs that developers never think to try on the code.
edit: some back of the envelope AI math:
To enumerate every unique state of a 64-bit variable, you must iterate through 18,446,744,073,709,551,616 individual inputs (2⁶⁴).
The exact time in seconds depends entirely on the processing speed of the system executing the loop. Here is how the time breaks down across three different performance levels:
1. Standard Desktop CPU (1 Billion operations/sec)
• Time: 18,446,744,073 seconds
• Scale: Roughly 584.5 years
• Context: If a single core on a modern processor handles roughly 1 billion state evaluations per second (1 GHz efficiency), it would take nearly six centuries to finish.
• Context: If you maximize a consumer CPU utilizing multiple threads or an incredibly high single-core instruction-per-clock rate (4.29 GHz efficiency), it still takes well over a human lifetime.
• Context: A highly optimized, massively parallel hardware setup—like an enterprise GPU cluster capable of churning through 1 Terahash/Tera-iteration per second—can shrink this problem down to a matter of months.
ferrisjoke 21 hours ago [-]
I've heard the joke many times, but I didn't expect that even programming would ever end up wanting to evolve to crabs.
akersten 20 hours ago [-]
> If you use our alpinelinux/gitlab container image, pull alpinelinux/gitlab:19.3.6 again. The image published on October 27 contains Ruby 3.3.13. Any 19.3.6 image you pulled before October 27, and all older tags, are vulnerable.
shouldn't they tag a new version instead of re-releasing a fixed 19.3.6, if earlier 19.3.6 are vulnerable?
looperhacks 18 hours ago [-]
Image tags are not are versions and shouldn't be treated as such. The tag "19.3.6" refers to the version of Gitlab, which hasn't changed. This is why everyone should pin their images to a specific sha and setup a process to get notified on changes
chrisweekly 11 hours ago [-]
that's incredibly confusing.
what's the point of the tag if the version is really the sha it happens to now point to?
it only looks like semver?
nullify88 16 hours ago [-]
Using Renovate can be one of those processes.
jtchang 22 hours ago [-]
This is a fantastic write up on the security incident. Almost any incident like this will have unknowns. It's good to make it explicit. I especially liked the part of what would have been leaked if the attacker was successful. Maybe they could include what type of hash was used.
rollulus 16 hours ago [-]
With the eMudhra situation we saw e.g. Go doing an emergency release that blacklists the certs, while they aren’t shipped with Go, as a protection of dependencies that haven’t caught up.
In this situation, wouldn’t the more responsible behaviour of gitlab be to blacklist Ruby runtimes that enable the CVE?
KronisLV 17 hours ago [-]
If Alpine prides themselves on focusing so much on security, they probably shouldn’t use GitLab - the attack surface is too great and it’s never going to be easy to keep safe and up to date fully, unless you have FTEs whose main job is just maintaining it.
Just get the source code of Forgejo, audit it thoroughly and run an instance of that.
I like Forgejo btw, but these days everything is vulnerable. Switching tools isn’t the final answer
KronisLV 13 hours ago [-]
Forgejo did and will in the future, same as GitLab.
The only difference is the architecture/moving parts/featureset which roughly corresponds to the attack surface, which then roughly corresponds to how many CVEs will be found, though that's also affected by how big a given target is.
That's not to say that Forgejo is some perfect piece of software, just that it builds on some of the past experience of Gitea and just has both less features than GitLab, is simpler, and also a smaller target. It will probably get >100 per year too soon, but I'd reckon that the totals will remain than GitLab for the foreseeable future.
Maybe I'm wrong!
dewey 10 hours ago [-]
> Just get the source code of Forgejo, audit it thoroughly and run an instance of that.
Or use the open-source version that is used by a lot of big companies and enterprises and has the enterprise features they actually need. Some of these will also have their own security team and would be flagging security issues to Gitlab in a hopefully responsible way.
There's no such thing as "just get the source and make sure there's no security issues". If it would be that easy don't you think Forgejo would've already done that?
qweqwe14 15 hours ago [-]
Thinking that Forgejo is a viable replacement for someone who uses GitLab is wild. It's a bit like telling someone to use cgit instead of Forgejo. (yes I know Alpine uses cgit as well)
KronisLV 13 hours ago [-]
Depends on the team and which of the actual features you use! As someone who introduced GitLab CI to my org as well, but runs most of my private stuff on Gitea + WoodpeckerCI, based on what I've seen there are A LOT of workflows that don't need that much out of GitLab, especially when you can move a lot of complexity into your CI solution alongside some light patches to the forge if necessary. Hell, I've seen people who haven't migrated off of SVN do okay (though personally I wouldn't punish myself like that).
ndsipa_pomu 9 hours ago [-]
If they switched to using the official Gitlab containers, then it's just a case of upgrading to a new version number when Gitlab sends a security email (about once a fortnight or so).
literallyroy 21 hours ago [-]
I feel like this title downplays the scenario. I read “attempted” as unsuccessful, not as maybe entirely successful.
rurban 18 hours ago [-]
This was happens when you don't trust existing well-maintained packages, and rather rewrite it by your own. Onigmo should not exist.
Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.
stevepike 21 hours ago [-]
Does anyone know for sure which unsupported versions of ruby are affected? Best I can tell 3 of the four affect old versions of ruby that are not getting a security patch for this. Update your ruby!
pretty nice to see that despite suspecting it wasnt really successful, a rebuild and thorough process was followed. lack of evidence doesnt mean nothing happened. better safe than sorry. classy response, hats off!
ab_wahab01 18 hours ago [-]
Is there any scanner that would catch this?
hemalathamadesw 9 hours ago [-]
wait can this happen inside a VPN?
wilson-draugr 19 hours ago [-]
The nasty part is that a version scan would have called that 19.3.6 image fixed. The CVE is filed against GitLab, and 19.3.6 is past the fixed version. The actual fix is in Ruby, and Ruby shipped it without requesting a CVE, so anything scanning the Ruby in the image has no advisory to match. If you build GitLab yourself, you had to read GitLab's release notes and then check which Ruby you were on.
milkshakes 18 hours ago [-]
not sure why this was flagged, it's completely on point.
Shekhartester 8 hours ago [-]
[flagged]
giozadi 10 hours ago [-]
[flagged]
bigoupea 10 hours ago [-]
[flagged]
vinaygundeti18 18 hours ago [-]
[dead]
23 hours ago [-]
23 hours ago [-]
udev4096 17 hours ago [-]
[dead]
z3ratul163071 17 hours ago [-]
use stupid software, win stupid prices. gitlab is overbloated human slop.
hhh 17 hours ago [-]
Gitlab is one of the best tools I have ever used... None of the competition even comes close in my experience. What do you recommend?
z3ratul163071 6 hours ago [-]
gitea
educar 15 hours ago [-]
gitlab is good software. what's wrong with it? granted it can be a bit slow if you are selfhosting and do not give the server enough resources.
ndsipa_pomu 9 hours ago [-]
Can you recommend a replacement that provides a git server and container repository?
z3ratul163071 6 hours ago [-]
gitea
m4tthumphrey 14 hours ago [-]
You clearly haven't used it.
z3ratul163071 6 hours ago [-]
i still use it because of a customer, unfortunately
andrewinardeer 22 hours ago [-]
Have researchers coined the term `Superbug` or `MegaVuln` yet?
Surely we're approaching a point where an LLM discovers a critical, unfixable vulnerability in every device running any version of $OS, then irresponsibly discloses it, triggering mass collective trauma among admins worldwide, significant downtime in critical infrastructure and scores of deaths.
missmewiththatl 22 hours ago [-]
We've adopted a zero-risk posture at our org. We've taken down numerous amounts of services over the last few weeks related to PHP, Node, and Python until things are properly vetted.
We joked in our last internal meeting that this is the end of public software... I have a feeling we may be right, at least in the very short term.
That's what Meltdown, Spectre, Rowhammer, and other hardware bugs have been. While you can't patch the hardware, there have always been software level mitigations.
Thankfully a lot of the low level stuff is just not that exposed to the network so even if you find a bug in some firmware, you still have to find a way to access it over the network.
> The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab.
I feel like this era of constant exploits/patches is really bad for those who build from source or make their own images vs those who rely on provided images and upgrade them often. I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting...
And zero trust makes sense, once one service behind a VPN is compromised attackers can potentially move laterally, zero trust mitigates that
For personal services, even something as simple as HTTP basic auth on the webserver dramatically reduces the attack surface by blocking all probers and drive-by attacks.
https://learn.microsoft.com/en-us/entra/identity/app-proxy/o...
If someone wants to vibe code an alternative to a SaaS tool, my gut feeling is "no, this is bad and it will blow up" as vibe-coded projects tend to do.
But then the alternative is often paying $X million per year for licenses to a half-assed program that hasn't had a UI update since 2005.
I just don't have a good argument on why they shouldn't when the outcome will be just as dogshit, only cheaper and flashier.
I don’t want them to change UI. I have plenty of work to do and have plenty of other tools that I use daily.
I have my workflows, I am swamped with work and now I have to change my workflows because someone changed options in UI where ones that O used are not there anymore.
I'm still using the 2024 version of JetBrains IDEs because the UI hadn't changed in over ten years. I quit paying JetBrains when they ripped out the perfectly functional UI and replaced it with a VSCode reskin.
Please, for the love of god, give me software with a consistent UI.
If they go ahead anyway, the ask is just that someone actually owns it after launch, not only builds it.
The fact that Jira/Confluence are being processed by their LLMs puts them in direct legal conflict with several statutes in the EU, its a matter of time for them to get hit by this and I’m betting that they think the fine will be lower than the revenue they acquire for doing it- and they’re hoping they don’t get hit at all.
This seems to be the common case for a lot of the non-EU tech companies, and it seems to be working.
Oracle is currently the market leader in “sovereign” compute for EU governments for example, as ironic as that is.
You don't need to be so hostile. I know about the EU requirements but many EU companies have sensitive data on hosted JIRA / Confluence that simply cannot be in the possession of a non-European company. I know because I'm working for one. I cannot even remote-work from outside Europe. Some stuff cannot even leave the VPN. There's also the CLOUD act.
They are constantly changing their software and settings. More than once they believed that something is legal but can be risky for the atlassian customer.
For example training AI on metadata which they believe are anonymized but are maybe not enough changed.
Training data or metadata permisson can not be configured on all subscriptions. But as a data processor they must follow the contract otherwise they become data controller.
Also there are risks associated with privacy data framework, cloud act etc. to be non compliant just by data transfers to other countries.
I’m doing my part!
https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-fo...
> We have not requested CVE identifiers in Ruby for these fixes, at least for now.
> Ruby has generally considered it unsafe to compile and use a regular expression created from untrusted input. We stated this in the advisory for CVE-2022-28738, where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment. We did the same for CVE-2024-27282.
Despite what anyone would try to sell you, a regular expression is a programming language. It's Always A Bad Idea (TM) to compile untrusted input into any kind of programming language. Don't string concatenate SQL queries, eval is evil, it's all the same idea.
i agree with you!
nevertheless,
> where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment
not sure what sort of comprehensive assessment is still called for at this point?
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
Security is always reactive by its very nature. You can do proactive things, but you will always be reactive to novel attacks.
Expect everything to have various levels of rolling upgrades, and soon. That's a lot of work.
When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.
It's not that it can't be done.
It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.
No, they won't :) This is the world now.
The future is near constant burning of tokens in your software factory to do this automatically. The labs create the increase in demand for their own product.
The way LLMs are developed now is but one possible future we could have experienced. Imagine the future where the LLMs were built by a few governments with black budgets and hidden until a war or some other large event broke out. Then suddenly most of the computers and digital infrastructure shits itself as everything goes wonky.
At least this way we get to see that a shared global infrastructure built on the idea that security is someone else's problem was a really bad idea and we might have enough time to fix it or pull enough plugs we don't go back to the dark age.
Alongside the current scanning and patching of software.
I don't think that lasts, I've seen at least 5 viable replacements now. All internal projects at major US companies.
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
In go, vendoring dependencies just copies the deps out of the module system into the local tree and it's managed the same as not vendoring. It won't even build of the go.mod has changed without also updating the vendor tree.
Who else is tired of C libraries since this week?
And now we are seeing that was all untrue.
How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.
https://www.darpa.mil/research/programs/translating-all-c-to...
We have a lot of legacy code that probably contains many bugs that could be exploited.
We could either stop using that legacy code, i.e. re-write and move to a newer library / package. Or fix the old code.
I now believe that "fixing" the code is actually in reach for an organization such as Google, which has deep pockets, frontier AI models, and a history of working on open source. Spend a few billions to walk through every package that runs on a common Linux installation, find potential issues and robustify the code.
The inspection/discovery part is what has accelerated; the fix, patch or rewrite, has not.
People smugly yelling on the internet to rewrite because they have a new toy isn't constructive - why aren't they out there doing it already?
Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).
But yes, memory-save languages like Rust are a massive help protecting against remote code execution. (unless said memory-safe language introduces its own category of RCE vulnerabilities, e.g. deserialization in Java)
Getting rid of C isn't the holy grail it might appear to be (Ubuntu has been working hard at rewriting sudo and coreutils in Rust and they have had plenty of bugs in the process), but I do hope the C projects will preemptively start fuzzing/running fil-C/invent new safety mechanisms for old code.
One of the points I wish more people understood about fuzzing is what it is doing is grabbing a random selection of all the possible inputs and running them through the function (Yes the fuzzer can be made to target/exercise different branches in the code, but it's still doing that with a random selection of the possible inputs that will exercise said piece of code).
Fuzzers miss bugs, because the full corpus of possible inputs is impossible to permutate through every function.
But the advantage of fuzzers is that they choose inputs that developers never think to try on the code.
edit: some back of the envelope AI math:
To enumerate every unique state of a 64-bit variable, you must iterate through 18,446,744,073,709,551,616 individual inputs (2⁶⁴).
The exact time in seconds depends entirely on the processing speed of the system executing the loop. Here is how the time breaks down across three different performance levels:
1. Standard Desktop CPU (1 Billion operations/sec)
• Time: 18,446,744,073 seconds
• Scale: Roughly 584.5 years
• Context: If a single core on a modern processor handles roughly 1 billion state evaluations per second (1 GHz efficiency), it would take nearly six centuries to finish.
2. High-End Multi-Core Processor (4.3 Billion operations/sec)
• Time: 4,294,967,296 seconds
• Scale: Exactly 136.1 years
• Context: If you maximize a consumer CPU utilizing multiple threads or an incredibly high single-core instruction-per-clock rate (4.29 GHz efficiency), it still takes well over a human lifetime.
3. High-End Enterprise GPU / Supercomputer Cluster (1 Trillion operations/sec)
• Time: 18,446,744 seconds
• Scale: Roughly 213.5 days
• Context: A highly optimized, massively parallel hardware setup—like an enterprise GPU cluster capable of churning through 1 Terahash/Tera-iteration per second—can shrink this problem down to a matter of months.
shouldn't they tag a new version instead of re-releasing a fixed 19.3.6, if earlier 19.3.6 are vulnerable?
In this situation, wouldn’t the more responsible behaviour of gitlab be to blacklist Ruby runtimes that enable the CVE?
Just get the source code of Forgejo, audit it thoroughly and run an instance of that.
I like Forgejo btw, but these days everything is vulnerable. Switching tools isn’t the final answer
The only difference is the architecture/moving parts/featureset which roughly corresponds to the attack surface, which then roughly corresponds to how many CVEs will be found, though that's also affected by how big a given target is.
For example, total new CVEs:
(a lot of the reporting out there sucks, cause some CVEs get assigned to Gitea and may or may not be applicable to Forgejo as well, so you have to dig into the details for example https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSear... and https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSear... and https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSear... )That's not to say that Forgejo is some perfect piece of software, just that it builds on some of the past experience of Gitea and just has both less features than GitLab, is simpler, and also a smaller target. It will probably get >100 per year too soon, but I'd reckon that the totals will remain than GitLab for the foreseeable future.
Maybe I'm wrong!
Or use the open-source version that is used by a lot of big companies and enterprises and has the enterprise features they actually need. Some of these will also have their own security team and would be flagging security issues to Gitlab in a hopefully responsible way.
There's no such thing as "just get the source and make sure there's no security issues". If it would be that easy don't you think Forgejo would've already done that?
Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.
I do think CVE-2026-89078 - the double free one - may only affect ruby 3.3.11 and above. It relies on a bug introduced in ruby 3.4/4 via https://github.com/ruby/ruby/commit/8cd295ecf0 and backported (maybe accidentally?) in 3.3.11/12 in https://github.com/ruby/ruby/commit/e02c892ade. So that one is getting patched on all rubies it would have affected.
Surely we're approaching a point where an LLM discovers a critical, unfixable vulnerability in every device running any version of $OS, then irresponsibly discloses it, triggering mass collective trauma among admins worldwide, significant downtime in critical infrastructure and scores of deaths.
We joked in our last internal meeting that this is the end of public software... I have a feeling we may be right, at least in the very short term.
https://news.ycombinator.com/item?id=50189092
Thankfully a lot of the low level stuff is just not that exposed to the network so even if you find a bug in some firmware, you still have to find a way to access it over the network.