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

461–470 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#461

Post by GoblinSlayer »

arter4 wrote: post #320
braiamp wrote: post #292

Earlier quoted context omitted.

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

As an outsider to this whole thing (having discovered this issue in this thread, like pretty much anyone), the CVE rules simply say that you cannot assign a CVE to vulnerabilities in a product that is not publicly available or licensable . Experimental, but publicly available features are still in scope. This makes sense IMHO: experimental features may be buggy, but they may work in your limited use case. So you may…

All features have limited use case, but experimental features may be buggy in all use cases, which is exactly what happened here. CVE is uninformative there, defects are implied, might as well create a CVE for every commit "something happened, don't forget to repedloy".

Re: Freenginx: Core Nginx developer announces fork

#462

Post by GoblinSlayer »

anon-sre-srm wrote: post #157
aaronbwebber wrote: post #147

Earlier quoted context omitted.

if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!

Incorrect. Features available to users still require a minimum, standard level of support. This is like the deceptive misnomer of staging and test environments provided to internal users used no differently than production in all but name.

Nobody does it like that though, what vendor declares unsupported is unsupported.

Re: Freenginx: Core Nginx developer announces fork

#464

Post by mistrial9 »

aftbit wrote: post #404

I dunno seems like a tempest in a teapot. Not sure why Maxim would not want CVEs to be assigned to something. Maybe it was just the final straw after a series of bad interactions. Every project has a lifespan, sometimes trying to keep them going forever is not the answer. I will miss nginx a lot if I need to migrate though.

no - the CVE process is at the center of new broad laws in the EU regarding business registration and security assurances. You are exactly wrong about the significance of this fork, basically.

see EU CRA

Re: Freenginx: Core Nginx developer announces fork

#465

Post by PH95VuimJjqBqy »

ryukoposting wrote: post #256
tky wrote: post #83

Earlier quoted context omitted.

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

This is confusing. The CVE doesn't describe the attack vector with any meaningful degree of clarity, except to emphasize how you'd have to have a known unstable and non-default component enabled. As far as CVEs go, it definitely lacks substance, but it's not some catastrophic violation of best practices. It hardly reflects poorly on Maxim or anything he's done for Nginx. This seems like an extreme move, and it makes…

it's most likely the last straw rather than the sole reason.

Re: Freenginx: Core Nginx developer announces fork

#466

Post by eddieroger »

nvarsj wrote: post #460
xorcist wrote: post #368

Earlier quoted context omitted.

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…

It doesn't drop mid request. But it closes the TCP socket abruptly after any in flight requests are completed. Clients have no idea the connection is closed, and try to reuse it and get back a RST. In heavily dynamic environments where nginx reloads happen frequently, it leads to large amounts of RSTs/broken connections and high error rates (you can't necessarily auto-retry a POST, a RST could mean anything). The san…

I'm late to return to the thread, but this was the exact scenario we hit. We had it behind a CDN as well as behind an L4 load balancer for some very high volume internal consumers, and when it would just blast back RST packets, the consumers would freak out and break connection, returning errors on their end that weren't matched in our logs, unless we were lucky and got a 499 (now Maxim can talk about standards). As a general purpose reverse proxy for many clients on the Internet, I'm sure that's fine, but in our use case this made nginx unpredictable and no longer desirable.

Re: Freenginx: Core Nginx developer announces fork

#467

Post by Communitivity »

arp242 wrote: post #248
mholt wrote: post #137

Earlier quoted context omitted.

I haven't read the content of the patches to understand the impact of the bugs, but from my own experience [0] I can suggest a few reasons: - CVEs are gold to researchers and organizations like citations are to academics. In this case, the CVEs were filed based on "policy" but it's unclear if they are just adding noise to the DB. - The severity of the bug is not as severe as greater powers-that-be would like to think…

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

Many security specialists via security as described by the CISSP material (Certified Information Systems Security Professional). Loosely speaking, that means ensuring the confidentiality, integrity, and availability of the system (including data received, data stored, and data sent).

Viewed in this light a bug that enables a successful Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack is a security bug. A bug that causes a DoS or DDoS, but is not exploitable, would not be a security bug (e.g., some idiot added an infinite loop to the startup code). That's where issue triage comes in, a bug should never be assigned before its triaged. Sometimes triage results in 'we don't know enough' and someone gets assigned to evaluate the bug to answer specific questions before triage can finished. After triage is get assigned - or even better, a developer with a matching skill set chooses it to work on for the next release/sprint/etc.

Re: Freenginx: Core Nginx developer announces fork

#468

Post by Gormo »

datashaman wrote: post #396
Gormo wrote: post #129

Earlier quoted context omitted.

> Also this is kind of why everything is ever so slightly broken, IMHO. OTOH, things that update too often seem to be more than slightly broken on an ongoing basis, due to ill-advised design changes, new bugs and regressions, etc.

If you want to move fast, you must accept that things break. If you want things not to break, you must slow down. It isn’t reasonable to ask for these two things at once: * lots of change * stability

And the reasonable answer is to judge proposed changes in terms of their impact to stability, and make relevant risk/reward tradeoffs (and ideally including risk mitigation within the scope of the change).

The current milieu seems dramatically skewed toward churning out low-value changes without sufficiently considering the impact to stability, causing frequent breakage, and resulting in net negative value.

Re: Freenginx: Core Nginx developer announces fork

#469

Post by breather »

Kwpolska wrote: post #456
fiscalnonsense wrote: post #440

Earlier quoted context omitted.

nginx is simultaneously a registered trademark of F5 and imnsho mouth garbage for English speakers. This is a good opportunity to rename the project.

It's pronounced "engine X".

Exactly—there's never been a better time to actually make the name look like it sounds.

Re: Freenginx: Core Nginx developer announces fork

#470

Post by arter4 »

PH95VuimJjqBqy wrote: post #465
ryukoposting wrote: post #256

Earlier quoted context omitted.

This is confusing. The CVE doesn't describe the attack vector with any meaningful degree of clarity, except to emphasize how you'd have to have a known unstable and non-default component enabled. As far as CVEs go, it definitely lacks substance, but it's not some catastrophic violation of best practices. It hardly reflects poorly on Maxim or anything he's done for Nginx. This seems like an extreme move, and it makes…

it's most likely the last straw rather than the sole reason.

Maybe, but he only mentioned disagreements on security policies. Doesn't sound very convincing as a last straw, especially from a marketing standpoint when trying to gain more traction for his fork.
Post reply on HN