Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

481–490 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#481

Earlier quoted context omitted.

This is an insane standard and attempting to adhere to it would mean that the CVE database, which is already mostly full of useless, irrelevant garbage, is now just the bug tracker for _every single open source project in the world_.

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?

You know that random thing you mucked around on Github X years ago then forgot about, and it's amongst 30 other random repos?

Should people file a CVE against that?

Re: Freenginx: Core Nginx developer announces fork

#482
So - The big question...

Is the fork going to allow you to change the nginx Server response header (A PAID feature in the current fork...) without requiring you to mod it in and recompile it? :p

Yes - You read that correctly. They refuse to accept PR's to add additional functionality because that functionality is restricted to the paid version :p

Re: Freenginx: Core Nginx developer announces fork

#483

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…

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

Or, just follow me here, a open source project really doesn't get that many dedicated contributors beyond the leads and everyone else may casually drive-by.

Re: Freenginx: Core Nginx developer announces fork

#484
I stop using Nginx when i needed ability to assign an Ethernet port (IP address not yet available) and Nginx developers refused to do this.

Before you ask why would I do that, Ive got all Ethernet interfaces on dynamically IP created on a on-demand basis and only wanted ONE specific interface (non-public) to host the HTTP/HTTPS protocol.

And no, we do not want to jerry-rig some fancy nginx config file shell -script updater whenever an IP address gets assigned/reassigned.

Here came lighthttpd and Apache to the rescue.

Re: Freenginx: Core Nginx developer announces fork

#485
post #460

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…

What you describe is basically how persistent http works, is it not? Even a persistent connection terminates at some point. Which web server does not work like that?

I guess you could send the connection header on draining, but anything less than what the big servers do is bound to cause some compatibility problem with some niche client somewhere. I can certainly see why a web server with millions of installs would be reluctant to change bevaviour, even if it is within spec.

I can only guess at the use case here, but maybe something designed from the start as a stateless proxy and not a general purpose web server would be a better fit.

Re: Freenginx: Core Nginx developer announces fork

#487
post #351

Earlier quoted context omitted.

Most of this simple premium features/plugins were probably funded by companies because they had business value. It's probably unlikely freenginx will re-create them without those contracts. Unpaid Open Source developers tend to focus on interesting/cool core stuff and ignore all the stuff businesses care about (like LDAP authentication).

Apache is unpaid and fully open source, though

And businesses prefer the open core Apache alternative.

Re: Freenginx: Core Nginx developer announces fork

#488
post #43

I admit I haven't followed closely this issue, but what is he talking about? >In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers’ position.

We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.

I worked there before and after the acquisition. F5 Security was woefully incompetent. We spent 3 months trying to get approval for a web hook from Gitlab -> Slack, including endless documents (Threat Model Assessment), and meetings - god, the meetings - at one point on a call with 35 people. So I feel Maxim’s pain trying to deal with that team at F5.

On the other hand nginx core developers (the Russians) were arrogant to the point of considering anyone else as inferior and unworthy of their attention or respect, unless they contributed to nginx oss. They managed that project secretively and rewrote most “outside” contributions. They also ignored security issues - one internal developer spotted security issues with NGINX Unit (a failed oss project 20 years out of date before it started) and was told to fix the issues quietly and not to mention “security” anywhere in the issue messages or commit history.

So I can imagine exactly how these meetings would have gone, I’m sure it was the last straw!

Re: Freenginx: Core Nginx developer announces fork

#489

Earlier quoted context omitted.

We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.

I worked there before and after the acquisition. F5 Security was woefully incompetent. We spent 3 months trying to get approval for a web hook from Gitlab -> Slack, including endless documents (Threat Model Assessment), and meetings - god, the meetings - at one point on a call with 35 people. So I feel Maxim’s pain trying to deal with that team at F5. On the other hand nginx core developers (the Russians) were arroga…

I can agree to this. I worked there too, and it took 2 months to get a simple approval for a similar project, despite preparing extensive TMA documents, etc
Post reply on HN