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.

It wasn't long ago that companies like Google were advocating for zero trust networks that avoid the need for VPNs!

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.

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.

This seems much more fundamental, less social, though.

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

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.

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.

Still not insane

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.

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.

now it's even more battle tested!

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.

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.

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

[profile.release] overflow-checks = true

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

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.

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?

Using Renovate can be one of those processes.

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.

For example, total new CVEs:

          2024 2025 2026
  Forgejo    1   10  >55 (confirmed ones, checked what I could)
  Gitea      1    9  121
  GitLab   145  165  251

(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!

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

gitea

gitea

i still use it because of a customer, unfortunately

your linux distro is built on perl and python

Hey hey, i called it!

https://news.ycombinator.com/item?id=50189092