Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

Post reply on HN
Print view View original

291–300 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#291

Post by manquer »

dspillett wrote: post #273
arp242 wrote: 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 That very much depends on what service is being denied. Nginx is _everywhere_. While not a direct security concern for nginx (instead an availablity issue) it could have security or safety implications for wider systems. What if knocking out nginx breaks a service for logging & monitoring security information? Or an ambulance call out management system? Or a payment progr…

We could argue that about almost anything though . There are always secondary effects possible and sometimes even likely. I can only think of the proverb/poem - "For want of a nail".

Re: Freenginx: Core Nginx developer announces fork

#292

Post by braiamp »

MZMegaZone wrote: post #272
mike_d wrote: 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…

What does policy says about reporting security issues with experimental/not-enabled-by-default/unstable code?

Re: Freenginx: Core Nginx developer announces fork

#293

Post by CoolCold »

kelnos wrote: post #150
bklyn11201 wrote: post #40

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.

A load balancer shouldn't serve static files. It shouldn't serve anything. It should... load balance. I can see why you'd want an all-in-one solution sometimes, but I also think a single-purpose service has strengths all its own.

Quite intersting - in theory, "pure" load balancer shouldn't not, but in practice most of my LBs, especially for small projects do. Even for larger projects I do combine proxy_cache on LB making it serve static files or using to serve websites public content and splitting load over several application servers for dynamic content.

And I think it's fine.

Re: Freenginx: Core Nginx developer announces fork

#294

Post by ironmagma »

whatever1 wrote: post #267
ironmagma wrote: post #77

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.

Meanwhile my anaconda installation died after a casual apt-get update lol I now believe that every piece of software should be shipped as a container to avoid any system library dependencies.

That is what Snap is for, but there are… issues

Re: Freenginx: Core Nginx developer announces fork

#296

Post by CoolCold »

dingnuts wrote: post #84
bklyn11201 wrote: post #40

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.

I keep a Caddy server around and the config format is actually much, much nicer than nginx's in my experience. The main problem with it is that everybody provides example configurations in the nginx config format, so I have to read them, understand them, and translate them. This works for me because I already knew a fair bit about nginx configuration before picking up Caddy but it really kills me to see just how many…

How would you imagine this in practice? Should one to provide instructions how to unwrap docker images/dockerfiles project uses (quite many do lean on Docker/Containers nowadays and not regular system setup) to for example setup the same on FreeBSD Jails? Where to stop here?

Re: Freenginx: Core Nginx developer announces fork

#297

Post by arp242 »

dspillett wrote: post #273
arp242 wrote: 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 That very much depends on what service is being denied. Nginx is _everywhere_. While not a direct security concern for nginx (instead an availablity issue) it could have security or safety implications for wider systems. What if knocking out nginx breaks a service for logging & monitoring security information? Or an ambulance call out management system? Or a payment progr…

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 all of this inconvenient and (potentially) a serious problem? Sure. But not "zomg criminals have credit card records / can spoof random domains / read private data / etc. etc." type serious.

Re: Freenginx: Core Nginx developer announces fork

#298

Post by cryptonym »

BigJono wrote: post #288
1vuio0pswjnm7 wrote: post #226

Earlier quoted context omitted.

IME, the best software is written by "1 or 2" people and the worst software is written by salaried teams. As an end user, it's only the encroachment by the later that scares me.

Yep. IME the only way to make a salaried team of 10 devs work efficiently is to have enough work that you can split it cleanly into 5-10 projects that 1-2 people can own and work on autonomously. Too bad every team I've ever worked on as a consultant does the opposite. The biggest piles of shit I've ever seen created have all been the product of 10 people doing 2 people's worth of work...

On one hand projects developed by 2 passionate devs ; on the other hand a team of entry to mid level devs working on someone else's project for the money.

That team changes every 6 month when another company offers more money. If only one or two people are working on a project, that's a high risk for the company.

If you got one or two highly skilled people in that team of 10, you are lucky. Managers don't want them to work alone on their project, they want them to help the team grow.

Re: Freenginx: Core Nginx developer announces fork

#299

Post by webprofusion »

One of the most heavily used Russian software projects on the internet https://www.nginx.com/blog/do-svidaniya-igor-thank-you-for-n... but it's only marginally more modern than Apache httpd.

In light of recently announced nginx memory-safety vulnerabilities I'd suggest migrating to Caddy https://caddyserver.com/

Re: Freenginx: Core Nginx developer announces fork

#300

Post by m_sahaf »

eropple wrote: post #209
francislavoie wrote: post #133

Earlier quoted context omitted.

LLMs do a horrendous job with Caddy config as it stands. It doesn't know how to differentiate Caddy v0/1 config from v2 config, so it hallucinates all kinds of completely invalid config. We've seen an uptick of people coming for support on the forums with configs that don't make any sense.

For just blasting a config out, I'm sure there are tons of problems. But (and I have not been to your forums, because...the project just works for me, it's great!) I've had a lot of success having GPT4 do the first-pass translation from nginx to Caddy. It's not perfect, but I do also know how to write a Caddyfile myself, I'm just getting myself out of the line-by-line business.

You could've used the nginx-adapter and skip the faulty LLMs

https://github.com/caddyserver/nginx-adapter

Post reply on HN