Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

381–390 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#381
post #356

Earlier quoted context omitted.

Nginx abruptly drops http/1.1 persistent connections on reloads. This has been an issue forever and Maxim refused to ever fix it, saying it was to spec (yes it was, but there are better ways to deal with it). It’s a reason why many large, modern infra deployments have moved away from nginx.

It doesn't drop it, it's just not persistent on reload, isn't that what you mean? Actually dropping a connection mid-request is something I haven't seen nginx (or indeed Apache) do for many years despite doing some weird things with it. I can see where you're coming from, but it's not unreasonable behaviour, is it? Connections needs to migrated over to the new worker and that's how all major servers do it. If that's…

Isn't the typical behaviour of an application to re-establish the persistent connection on demand? I wonder what the requirement is to have these persistent with no timeout.

Re: Freenginx: Core Nginx developer announces fork

#382
post #258

Earlier quoted context omitted.

QUIC in Nginx is experimental and not enabled by default. I tend to agree with him here that a WIP codebase will have bugs that might have security implications, but they aren't CVE worthy.

We know a number of customers/users have the code in production, experimental or not. And that was part of decision process. The security advisories we published do state the feature is experimental. When in doubt, err on the side of doing the right thing for the users. I find that's the best approach. I don't consider CVE a bad thing - it shouldn't be treated like a scarlet letter to be avoided. It is a unique ident…

FWIW, in my project the main reason we don't issue security advisories for "unsupported" code ("experimenal" or "tech preview") is to reduce the burden for our downstreams: many of our immediate downstreams are expected by their users to apply every single security patch, regardless of whether they even use the affected functionality. For cloud providers doing this across a massive fleet, this is a fair amount of work that's worth avoiding if we can.

On the other hand, since the definition of "supported" is specifically designed to help downstreams, if it were known that some bit of code was widely used in production, we'd be open to declaring it "security supported", regardless of whether we thought it was "finished" or not.

Re: Freenginx: Core Nginx developer announces fork

#383
post #297

Earlier quoted context omitted.

Almost every bug can be considered a security bug under the wrong set of circumstances. With fairly cheap ddos services you can "just" order you can knock most servers offline anyway. Internet reachability is rarely safety-critical, and if it is, that's probably a huge design flaw somewhere because there's tons of reasons outside of your control that can make the internet not work for either the server or clients. Is…

> Almost every bug can be considered a security bug [...] With fairly cheap ddos services... A DoS bug and an DDoS attack are very different things. One is a flaw that can bring a service down, the other is a brute force technique for making a service unusable. You can DDoS services without exploiting bugs.

I am aware; my point is that "denying the service" is pretty easy even without the presence of any bugs in the service. Stealing credit cards on the other hand...

Re: Freenginx: Core Nginx developer announces fork

#384
post #117

Earlier quoted context omitted.

I completely get this. I feel like every product I’ve had outside of a vendor’s wheelhouse has gone that way. We just use the BigIP gear from F5 and they’re better than the load balancers we used in the past. Thank god Cisco just abandoned that business. I can’t imagine them supporting telco gear. The IPv6 thing has me LOLing because I just had a similar experience with a vendor where we don’t route IPv6 in that segm…

> I have a list of “thou shalt not” companies Can you share that list?

First, I don’t make these decisions but sometimes have influence. These opinions are my own and not my intentionally unnamed employer, and might be flat out wrong. This list is very focused on big companies at stupid scale with a lot of legacy… applied tech.

Generally my rule is “except for their very core product.” But this is full “hate everything” that pops into my mind:

RedHat won’t accept gifted patches for critical bugs in their tools that they won’t troubleshoot themselves. Getting the patch upstream means you get to use it in the next major version years later. That predates IBM. I won’t use their distribution specific tooling anymore. Outside the OS sucks worse. If I hear ActiveMQ one more time… [caveat: I probably hate every commercial Linux distro and Windows because my nonexistent beard is grayer than my age]

IBM… kind of feel sad about it, but they now suck at everything.

Oracle has good support, but they’re predatory and require an army of humans to manage inherently hodgepodge systems. Also creates an organizational unit of certified admins that can’t transition to alternatives because they’ve only memorized the product. Cisco’s the same except the predatory part and without many good alternatives for core DC gear.

CA, Symantec were awful pre-Broadcom and even worse now that they’re Broadcom’s annuity. Where products go to die.

Trellix (ex McAffee) is like the new Symantec or something.

There’s more I wish I could list for you, but can’t for various reasons.

On the other end, Satya has made MS a reasonable choice in so many things. Still a lot that sucks or is immature, but still… I didn’t think that was possible. I had to shift my mindset.

Re: Freenginx: Core Nginx developer announces fork

#385

Earlier quoted context omitted.

typo? it forwards to https anyway.

Pretty sure that's an extension on your part. Neither chrome/firefox/cURL redirects that to https for me.

you're right I forgot about https auto forwarding in my browser as default.

Re: Freenginx: Core Nginx developer announces fork

#386
post #92

Earlier quoted context omitted.

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…

You bring up NGINX+, a commercial product with a CVE reporting policy, but just from reading the docs on it it doesn't support QUIC or HTTP/3. So I guess I can see why the maintainer would be mad about a commercial policy applying to noncommercial work in the absence of any real threat.

Re: Freenginx: Core Nginx developer announces fork

#387
post #380
post #248

Earlier quoted context omitted.

"Denial of service" is never a security bug; it's a huge mistake people have started classifying these things as such to start with. Serious bug? Sure. Loss of security? Not really.

> "Denial of service" is never a security bug. What about serving certificate revocation list, with another system relying on say one day old cache? (Sure, that's "fail open" - but still...). Or proxying LDAP for sync to a central auth/authz system? Ed: proxy giving access to logging system goes down - alert on failed logins silenced, disabling rate limits for brute force attacks?

Almost any bug in those kind of systems are potential security bugs. Not having the service available at all is probably among the least critical type of bug that can happen.

Re: Freenginx: Core Nginx developer announces fork

#388
post #307

Earlier quoted context omitted.

tangent but i havent seen that happen on any of my putty clients in years and i use it everyday, so i think that finally got fixed? or maybe was a side effect of something stupid

next question: why are people still using putty

its great for serial and raw on windows.

Re: Freenginx: Core Nginx developer announces fork

#389
post #307

Earlier quoted context omitted.

next question: why are people still using putty

Why shouldn't people use putty? I still use putty because it does what I need for it to do. No need to change just because MS has their own terminals application, which besides I far from trust.

You trust them to run the entire OS and every stack included in it, but not to make an ssh client?

Re: Freenginx: Core Nginx developer announces fork

#390
post #330
post #315

Earlier quoted context omitted.

Putty met my needs in 2004 and my needs haven't changed. It still works as good in 2024. I'm not 100% sure when I started using putty, but I definitely used it in 2004. I still need a ssh client and terminal emulator for Windows. I still don't want to install a unix like environment just to have a terminal. I still don't want tabs in my terminal, lots of windows works just fine. I still need X11 forwarding so I can r…

The difference in 2024 is that windows ships openssh client and server as a built-in optional component and it also ships a workable terminal emulator. No WSL needed in either case. (But yeah I'm still using putty, too)

Microsoft stopped shipping HyperTerminal, last I checked. It wasn't really worth the effort to make it do SSH.

I'm not really a fan of cmd or powershell, although I guess I could use them in a pinch. Wouldn't look like what I'm used to though. :p

Post reply on HN