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

471–480 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#471

Post by callahad »

yakshaving_jgt wrote: post #449
callahad wrote: post #367

Earlier quoted context omitted.

That's been fixed for years. The CVE I can find was resolved in 1.17.7 (Dec 2019), and further hardening was applied in 1.21.1 (Jul 2021).

Can nginx send requests upstream over HTTP/2? I see this question has remained unanswered for a couple of years. https://security.stackexchange.com/questions/257823/what-are...

It cannot. There's more detailed reasoning at https://trac.nginx.org/nginx/ticket/923, but the tl;dr is:

> nginx is already good at mitigating HTTP desync / request smuggling attacks, even without using HTTP/2 to backends. In particular because it normalizes Content-Length and Transfer-Encoding while routing requests (and also does not reuse connections to backend servers unless explicitly configured to do so)

Re: Freenginx: Core Nginx developer announces fork

#472

Post by mort96 »

tangus wrote: post #131
ddxv wrote: post #102

Earlier quoted context omitted.

Why wouldn't he want CVEs assigned?

>The most recent "security advisory" was released despite the fact that the particular bug in the experimental HTTP/3 code is expected to be fixed as a normal bug as per the existing security policy, and all the developers, including me, agree on this. >And, while the particular action isn't exactly very bad, the approach in general is quite problematic.

What does any of that have to do with assigning a CVE?

Re: Freenginx: Core Nginx developer announces fork

#473

Post by mort96 »

aaronbwebber wrote: post #147
Twirrim wrote: post #127

Earlier quoted context omitted.

I'm inclined to agree with your decision to create and publish CVEs for these, honestly. You were shipping code with a now-known vulnerability in it, even if it wasn't compiled in by default.

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

That .. is the definition of shipping the code, the code is being shipped to the people downloading and compiling it for themselves

Re: Freenginx: Core Nginx developer announces fork

#474

Post by kayfox »

whoknowsidont wrote: post #249
xcrunner529 wrote: post #219

Earlier quoted context omitted.

Why is it insane? The CVE goal was to track vulnerabilities that customers could be exposed to. It is used…in public, released versions. Why wouldn’t it be tracked?

Because it's not actually part of the distribution unless you compile it yourself. It is not released any sense of the word. It is not even a complete feature. I am actually completely shocked this needs to be explained. Legitimate insanity.

Docs say its compiled into the Linux binaries by default:

http://nginx.org/en/docs/quic.html

"Also, since 1.25.0, the QUIC and HTTP/3 support is available in Linux binary packages."

Re: Freenginx: Core Nginx developer announces fork

#477

Post by [deleted] »

fiscalnonsense wrote: post #440
stemc43 wrote: post #61

Earlier quoted context omitted.

> not sure how much leg he has to stand on for using the word nginx itself in the new product’s name and domain pretty sure they can't really do anything to him in Russia. Russia and US don't recognize each others patents, same as China.

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

[deleted]

Re: Freenginx: Core Nginx developer announces fork

#478

Post by Sohcahtoa82 »

TedDoesntTalk wrote: post #184
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…

To summarize: the more CVEs a "security researcher" can say he created on his resume, the more impressive he thinks he looks. Therefore, the incentive to file CVEs for any stupid little problem is very high. This creates a lot of noise for developers who are forced to address sometimes nonsense that are filed as "high" or "critical".

So true...

If you run a web app of any sort, and you don't have "X-Frame-Options: Deny" in your headers, you'll get lots of "researchers" (that are probably bots) e-mailing you that you have a CRITICAL security issue.

"Beg bounties", we call them.

Re: Freenginx: Core Nginx developer announces fork

#479

Post by Reelix »

gav wrote: post #421
gwd wrote: post #382

Earlier quoted context omitted.

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 wo…

Recently I had to support a client who had a "no CVEs in a production deploy, ever" policy. The stack included Linux, Java, Chromium, and MySQL. It took multiple person-years of playing whack-a-mole with dependencies to get it into production because we'd have to have conversations like: Client: there's a CVE in the this module Us: that's not exploitable because it's behind a configuration option that we haven't enab…

In their defense, if the latest version of a module has a CVE, then it's either a 0-day, or an unsupported module.

In either case, you should probably do something about it.

Re: Freenginx: Core Nginx developer announces fork

#480

Post by Reelix »

JackSlateur wrote: post #378
MZMegaZone wrote: post #272

Earlier quoted context omitted.

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…

The question I ask is "Why not assign a CVE?" Exactly: why not ? Glory to the Linux Kernel which is on its way to assign CVE for everything :)

EVERYTHING.

Found a missing comma in the documentation of a function? Yup - That's a CVE ;p

Post reply on HN