Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

271–280 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#271

Earlier quoted context omitted.

I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...

Given how frequently people copy and paste example code… why is that surprising? Folks need to be informed. CVEs are a channel for that.

Pssst: People who copy+paste example code aren't checking CVEs

Re: Freenginx: Core Nginx developer announces fork

#272
post #258

Earlier quoted context omitted.

Yes, those are the two CVEs I was referring to. All I know is he objected to our decision to assign CVEs, was not happy that we did, and the timing does not appear coincidental.

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 identifier that makes it easy to talk about a specific issue and get the word out to customers/users so they can protect themselves. And that's a good thing.

The question I ask is "Why not assign a CVE?" You have to have a solid reason why not to do it, because of default is to assign and disclose.

I don't think having the CVEs should reflect poorly on NGINX or Maxim. I'm sorry he feels the way he does, but I hold no ill will toward him and wish him success, seriously.

Re: Freenginx: Core Nginx developer announces fork

#273
post #248
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.

> "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 progressing system for your business at the busiest time if your trading year? There are many other such examples. This sort of thing is why availablity can be considered a security matter and therefore why DoS vulnerabilities, particularly those affecting common software, are handled as security issues of significant severity.

Re: Freenginx: Core Nginx developer announces fork

#274
post #154

Earlier quoted context omitted.

If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.

BRB, filing CVE's against literally any project with example code in their documentation...

That's actually supported by the CVE program rules. Have at it if you find examples with security vulns.

Re: Freenginx: Core Nginx developer announces fork

#275

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.

You're all also missing the fact that the vuln is also in the NGINX+ commercial product, not just OSS. Which has a different release model.

Being the same code it'd be darn strange to have the CVE for one and not the other. We did ask ourselves that question and quickly concluded it made no sense.

Re: Freenginx: Core Nginx developer announces fork

#276

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.

[dead]

Re: Freenginx: Core Nginx developer announces fork

#277
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…

I don't know much about this situation, but from what I've read, you were clearly in the right. It doesn't matter if the feature is in optional/experimental code. If it's there and has a vulnerability, give it a CVE. The customers/users can choose how much they care about it from there.

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

I recently did exactly that when a vendor refused to obtain a CVE themselves. In my case, I was doing it as part of an effort to educate the vendor on how CVEs worked.

Re: Freenginx: Core Nginx developer announces fork

#278

Earlier quoted context omitted.

And that's how 100x developers don't get the recognition they deserve.

Philosophically, if a lead developer is doing most of the commits on a project, then they are monopolizing both the code and the decision making process, which is a sure way to kill a project. If the basketball or soccer team captain were also a ball hog, they'd have trouble keeping the bench full. When you become lead, you have to let some of the code go, and the best way I know to do it is to only put your fingers…

I think there are problems where this will apply to, such as crud applications, and projects where deep understanding of core components makes it difficult to scale teams horizontally as it will effectively require a hive-mind.

Re: Freenginx: Core Nginx developer announces fork

#280
post #45

This isn’t just “a core nginx dev” — this is Maxim Dounin! He is nginx. I would consider putting his name in the title. (And if I were F5, I’d have given him anything he asked for to not leave, including concessions on product vision.) That said, I’m not sure how much leg he has to stand on for using the word nginx itself in the new product’s name and domain…

He *is* nginx ? https://freenginx.org/hg/nginx I don't see it. Sure, he contributes. But in the last 3-4 years he definitely does not look like he is nginx based on that log. Or am I looking in the wrong place?

[deleted]
Post reply on HN