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

431–440 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#431

Post by bnolsen »

Twirrim wrote: post #262
whoknowsidont wrote: post #249

Earlier quoted context omitted.

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.

It's in the published source code, as a usable feature, just flagged as experimental and not compiled by default. It's not like this is some random development branch. It's there, to be used en route to being stable. People will have downloaded a release tagged version of the source code, compiled that feature in and used it. By what definition is that not shipped? > I am actually completely shocked this needs to be…

I've had an optional experimental feature marked with a CVE. It's not a big deal as it just lets folks know that they should upgrade if they are using that experimental feature in the affected versions.

Re: Freenginx: Core Nginx developer announces fork

#432

Post by MZMegaZone »

statquontrarian wrote: post #350
MZMegaZone wrote: post #275

Earlier quoted context omitted.

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.

"made no sense" from a narrow, CVE announcement perspective, but Maxim disagrees from another perspective: > [F5] decided to interfere with security policy nginx > uses for years, ignoring both the policy and developers’ position. > > That’s quite understandable: they own the project, and can do > anything with it, including doing marketing-motivated actions, > ignoring developers position and community. Still, this…

OK - I need to make very clear that I'm speaking for myself and NOT F5, OK? OK.

Ask yourself why this matters? What is the big deal about having a CVE assigned? A CVE is just a unique identifier for a vulnerability so that everyone can refer to the same thing. It helps get word out to users who might be impacted, and we know there are sites using this feature in production - experimental or not. This wasn't dictating what could or could not go into the code - my understanding was the vuln wasn't even in his code, but from another contributor. So, honestly, how does issuing the CVEs impact his work, at all?

That's what I, personally, don't understand. At a functional level, this really has no impact on his work or him personally. This is just documentation of an existing issue and a fix which had to be made, and was being made, CVE or no CVE. And this is worth a fork?

What you're suggesting is the best thing to do is to allow one developer to dictate what should or should not be disclosed to the user base, based on their personal feelings and not an analysis of the impact of that vulnerability on said user base? And if they're inflexible in their view and no compromise can be reached then that's OK?

Sometimes there's just no good compromise to be reached and you end up with one person on one side, and a lot of other people on the other, and if that one person just refuses to budge then it is what it is. Rational people can agree to disagree. In my career there have been many times when I have disagreed with a decision, and I could either make peace with it or I could polish my resume. To me it seems a drastic step to take over something as frankly innocuous as assigning a CVE to an acknowledged vulnerability. Clearly he felt differently, and strongly, on the matter. Maybe he is just very strongly anti-CVE in general, or maybe he'd been feeling the itch to control his own destiny and this was just the spur it took to make the move.

His reasons are his own, and maybe he'll share more in time. I'm comfortable with my personal stance in the matter and the recommendations I made; they conform with my personal and professional morals and ethics. I'm sorry it came to this, but I would not change my recommendation in hindsight as I still feel we did the right thing.

Only time will tell what the results of that are. I think the world is big enough that it doesn't have to be a zero sum game.

Re: Freenginx: Core Nginx developer announces fork

#433

Post by MZMegaZone »

conartist6 wrote: post #386
MZMegaZone wrote: post #106

Earlier quoted context omitted.

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…

You bring up NGINX+, a commercial product with a CVE reporting policy, but just from reading the docs on it it doesn't support QUIC or HTTP/3. So I guess I can see why the maintainer would be mad about a commercial policy applying to noncommercial work in the absence of any real threat.

https://www.nginx.com/blog/quic-http3-support-openssl-nginx/

I know there are other mentions - it's been in the commercial product since R30, hence the CVE.

Re: Freenginx: Core Nginx developer announces fork

#434

Post by MZMegaZone »

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…

That's just a braindead policy.

Really, really dumb. Not at all good security, just checking boxes.

Re: Freenginx: Core Nginx developer announces fork

#435

Post by stemc43 »

ale42 wrote: post #361
nicolas_17 wrote: post #97

Earlier quoted context omitted.

What do patents have to do with this?

Many people seem to confuse trademarks and patents...

i know the difference i just don't care enough. same thing applies - u would gave to register business and trademark in Russia and pay taxes to have any legs

Re: Freenginx: Core Nginx developer announces fork

#436

Post by liveoneggs »

nly wrote: post #351
perlgeek wrote: post #328

Earlier quoted context omitted.

I remember being surprised by the open core thing some years ago. I had been an Apache user for quite some time, and thought I'd take a look at the (at that point, a few years old) "new" shiny thing. I found that something as simple as LDAP authentication required a payed plugin; a free Apache module has been available for this for ages. That made nginx a non-starter for this particular use case. I wonder if the fork…

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

Re: Freenginx: Core Nginx developer announces fork

#437

Post by ImPostingOnHN »

bemusedthrow75 wrote: post #332
ImPostingOnHN wrote: post #240

Earlier quoted context omitted.

> clearly didn't bother the developer of freenginx while they were paying him Clearly it did, so much so that he gave up all that pay.

That is not why he gave up all the pay, is it? F5 closed the Moscow office.

You are right, my mistake.

Re: Freenginx: Core Nginx developer announces fork

#438

Post by hinkley »

goodpoint wrote: post #344
hinkley wrote: post #317

Earlier quoted context omitted.

Good luck with your empire building sans team building.

How about we live without empires?

> then they are monopolizing both the code and the decision making process, which is a sure way to kill a project.

I believe that was my thesis. Who are you agreeing with here?

Re: Freenginx: Core Nginx developer announces fork

#439

Post by gwd »

MZMegaZone wrote: post #434
gav wrote: post #421

Earlier quoted context omitted.

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…

That's just a braindead policy. Really, really dumb. Not at all good security, just checking boxes.

I mean, yeah, but if that's the way big bureaucratic organizations get sometimes. Bigger means more likely to have a brain-dead policy like this, but also more money... so, do you give up the money, or do you accommodate their policy while trying to minimize the cost?

Re: Freenginx: Core Nginx developer announces fork

#440

Post by fiscalnonsense »

stemc43 wrote: post #61
ComputerGuru wrote: post #35

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…

> 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.
Post reply on HN