Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

101–110 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#101

Earlier quoted context omitted.

Hm. I guess this consultancy-on-a-paid-version model doesn't bother me (and clearly didn't bother the developer of freenginx while they were paying him). But a double fork can't be good.

I assume USA companies are by far the highest revenue source for Nginx Plus. Both of these forks seem to be based in Russia. How is a USA company supposed to pay either of these vendors for their consulting or Pro versions? How long until F5 submits requests for domain ownership of freenginx.org, and how quickly does Angie get takedown requests for their features that look remarkably similar to Nginx Plus features (e…

> features that look remarkably similar to Nginx Plus features (e.g., the console)

Its illegal for products in the same space to have similar features?

Re: Freenginx: Core Nginx developer announces fork

#103
post #69

Earlier quoted context omitted.

I dunno about rock solid. I’ve had plenty of issues forcing a failover/reboot, multiple complicated tickets open a year, etc. But we have a sh ton of them. To be fair, some are kernel bugs with connection table leaks, SNAT + UDP, etc. Buuuut, they have by far the best support. They’re as responsive as Cisco, but every product isn’t a completely different thing, team, etc. And they work really well in a big company us…

I'm very out of date so take my opinion with a grain of salt. The customer support I received from F5 when they acquired a telco product was about the worst support I've ever seen. Now this wasn't the general LB equipment that F5 has the reputation around, it's some specific equipment for LTE networks. We'd get completely bogus explanations for bugs, escalate up the chain to VPs and leadership because there was an ob…

When was this? I worked with them 2009-2018, support was really top notch. We could get super technical guys on the call and even custom patches for our issues, but our usage was relatively simple. I contrast them with McAfee products we've used, now that was a complete shitshow as a product and support.

Re: Freenginx: Core Nginx developer announces fork

#104

It is scary to think about how much of web relies on projects maintained by 1 or 2 people.

Not that scary when you remember there are some systems that haven't been significantly updated for decades (e.g. the Linux TTY interface). A lot of stuff can just coast indefinitely, you'll get quirks but people will find workarounds. Also this is kind of why everything is ever so slightly broken, IMHO.

Not the web though

Re: Freenginx: Core Nginx developer announces fork

#106
post #92

Earlier quoted context omitted.

No, a MegaZone. Haven't you heard, we come in six packs now. ;-) Yeah, very, very likely one and the same. Since 1989.

Wow, that's a throwback. I was an ISP person back in the Portmaster era. You're at F5 now, I guess! Can you say more about the CVE thing? That seems like the opposite of what Maxim Dounin was saying.

Yeah, I've been with F5 since 2010 - gotta love those old PortMasters though, Livingston was good times, until Lucent took over. I was there 95-98.

I don't know what else there is to say really. The QUIC/HTTP/3 vuln was found in NGINX OSS, which is also the basis for the commercial NGINX+ product. We looked at the issue and decided that, by our disclosure policies, we needed to assign a CVE and make a disclosure. And I was firmly in that camp - my personal motto is "Our customers cannot make informed decisions about their networks if we do not inform them." I fight for the users.

Anyway, Maxim did not seem to agree with that position. There wasn't much debate about it - the policy was pretty clear and we said we're issuing a CVE. And this is the result as near I can tell.

Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.

Re: Freenginx: Core Nginx developer announces fork

#108
post #47

Time for me to slowly start looking for an alternative. There was a time when I wanted to move away from it and was eyeing HAProxy, but the lack of the ability to serve static files didn't convince me. Then there was Traefik, but I never looked too much into it, because Nginx is working just fine for me. My biggest hope was Cloudflare's Rust-based Pingora pre-announcement, which was then never published as Open Sourc…

I mean I’m not sure how it’s good to want to move to a dev who is against CVEs and disclosures…

Re: Freenginx: Core Nginx developer announces fork

#109
post #93

Earlier quoted context omitted.

HAProxy is a wonderful load balancer that doesn't serve static files thus forcing many of us to learn Nginx to fill the static-file-serving scenarios. Caddy seems like a wonderful alternative that does load balancing and static file serving but has wild config file formats for people coming from Apache/Nginx-land.

That's the best part -- you can choose your config format when using Caddy! https://caddyserver.com/docs/config-adapters

True and I've made use of the Nginx adapter, but the resulting series of error messages and JSON was too scary to dive in further. The workflow that would make the most sense to me (to exit Nginx-world) would be loading my complex Nginx configs (100+ files) with the adapter, summarizing what could not be interpreted, and then writing the entirety to Caddyfile-format for me to modify further. I understand that JSON to Caddyfile would be lossy, but reading or editing 10k lines of JSON just seems impossible and daunting.

Re: Freenginx: Core Nginx developer announces fork

#110

Earlier quoted context omitted.

Not that scary when you remember there are some systems that haven't been significantly updated for decades (e.g. the Linux TTY interface). A lot of stuff can just coast indefinitely, you'll get quirks but people will find workarounds. Also this is kind of why everything is ever so slightly broken, IMHO.

That only helps if it stays static. For example, if the Linux TTY interface was unchanged for decades to such a degree that nobody worked on it, but then had a vulnerability, who would be able to fix it quickly?

Perhaps someone with more knowledge can chime in. But, my impression is that there are vulnerabilities with TTY, it's just that we stay educated on what those are. And we build systems around it (e.g. SSH) that are secure enough to mitigate the effects of those issues.
Post reply on HN