Core NGINX Developer Forks Web Server Into Freenginx

[S.Pam]

Well I have one data point for you, I switched from nginx to Caddy last year because I really wanted that sweet sweet HTTP/3 which nginx took their good time to implement and I was tired of waiting 💁

Me too, and found Caddy more than capable and really rather nice to work with.

[hf_139]

A well run nginx fork by one of the main developers is long overdue.
Lets hope that it can actually take over, establish itself and eventually replace those other nginx forks run by less experienced people who simply missed something.
Nginx was being crippled by corporate drama already before 2022, if we can leave that behind now, it might result in a better future than we would have gotten otherwise.

[Mangogeddon]

I too switched all of the sites I manage over to Caddy. It's just so much easier to manage out of the box, the configuration syntax is much better and getting built-in letsencrypt support is quite nice.

[quaz0r]

viva la revolucion

[mb_q]

Caddy also has an odd corporate relationship, with ZeroSSL (it is easy to have it issue ZeroSSL cert instead of Let's encrypt one if not paying attention). On the other hand, Nginx has strong ties to a particular authoritarian country which very much likes cyberwars and won't hesitate to use all its assets.

[sophisticles]

Someone needs to explain something to me, from the linked discussion:

We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues.

F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.

This seems like a much larger story than the fork, given the install base of nginx.

For clarity are you referring to CVE-2024-24989 and -24990 (HTTP/3)?

Yes, those are the two CVEs I was referring to. All I know is he objected to our decision to assign CVEs, was not happy that we did, and the timing does not appear coincidental.

I think you'd have to ask Maxim. My take is he felt experimental features should not get CVEs, which isn't how the program works. But that's just my take - I'm the primary representative for F5 to the CVE program and on the F5 SIRT, we handle our vuln disclosures.

My tiny little brain's take:

Why ship any project, especially one as widely used and important as NGINX, with any experimental feature that has known vulnerabilities?

How about you remove the code completely from the version you ship until you have the issue sorted out.

A CVE is basically an announcement that there is a known issue with the software, to my way of thinking it's like a pizzeria giving you a pizza with a disclaimer that the sauce that was used was expired.

Here's a crazy idea, use fresh sauce for the pizza and ship code that doesn't have known security issues.

In other words, don't issue a CVE, yank the damn code out.

[Drizzt321]

It's not entirely uncommon to have features shipped with big "EXPERIMENTAL" flags on it. Take the Linux kernel. It regularly ships with features or bits that are considered experimental, but requires specific flags to turn on. Either by compiling your own copy, or run-time parameters. Or it's experimental because they want to not have to maintain an extra full branch for a long time, but they still want to let users out in the wild experiment and play with the new functionality to get their feedback. And also find edge cases the developers didn't think of, or don't see. As long as it's managed to not endanger the other parts of the system, and have great big warning signs around it, it's not a bad way to let folks play around with it out in the wild.

[johncall]

Why ship any project, especially one as widely used and important as NGINX, with any experimental feature that has known vulnerabilities?

How about you remove the code completely from the version you ship until you have the issue sorted out.

Is there evidence to suggest that F5/NGINX knowingly shipped vulnerable code? Perhaps I'm being naive, but my mind assumed that some third-party found the vulnerabilities, disclosed them responsibly, and NGINX couldn't "unship" the code so they had to issue CVEs.

[higuita]

Nginx has strong ties to a particular authoritarian country which very much likes cyberwars and won't hesitate to use all its assets.

You are talking about F5 and the ties to the US government 3 letters agencies, right?! ;D
Don't be fooled, both side do the same, they both abuse their power for their gain (while claiming some random reason of the day) and smaller countries are the one that suffer and get destroyed by their games


As for freenginx, lets hope they make the useful features behind nginx paid versions available

[curfew]

Someone needs to explain something to me, from the linked discussion:
My tiny little brain's take:

Why ship any project, especially one as widely used and important as NGINX, with any experimental feature that has known vulnerabilities?

How about you remove the code completely from the version you ship until you have the issue sorted out.

It's called "experimental" because it's known to -- or at least expected to -- be broken. It exists for customers to EXPERIMENT on those features in order to be ready for when they are actually mature, tested and stable. Hell, they could even provide feedback for improving the feature.

Security problems don't make any difference because nobody should enable those experimental features in publicly accessible environments.