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

421–430 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#421

Post by gav »

gwd wrote: post #382
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…

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 enabled
  Client: somebody could turn it on
  Us: even if they somehow did and nobody noticed, they would have to stand up a server inside your VPC and connect to that
  Client: well what if they did that?
  Us: then they'd already have root and you are hosed 
  Client: but the CVE
  Us:
So I definitely appreciate any vendor that tries to minimize CVEs.

Re: Freenginx: Core Nginx developer announces fork

#424

Post by RamRodification »

austinjp wrote: post #416
robgibbons wrote: post #412

It was already mentioned in the other thread, but it looks like F5 owns the trademark for the Nginx name. Maxim should consider rebranding the project to avoid any legal blowback.

As I suggested elsewhere [0] if you bump each letter in nginx you get... ohjoy! [0] https://news.ycombinator.com/item?id=39376657

Fun but bad!

Re: Freenginx: Core Nginx developer announces fork

#425

Post by temp0826 »

austinjp wrote: post #416
robgibbons wrote: post #412

It was already mentioned in the other thread, but it looks like F5 owns the trademark for the Nginx name. Maxim should consider rebranding the project to avoid any legal blowback.

As I suggested elsewhere [0] if you bump each letter in nginx you get... ohjoy! [0] https://news.ycombinator.com/item?id=39376657

I feel like scrambling the letters to "ginnx" (pronounced jinx?) or something might be better.

Re: Freenginx: Core Nginx developer announces fork

#426

Post by yankaf »

ComputerGuru wrote: post #68
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.

It's a .org domain, the registry is held in the USA.

[flagged]

Re: Freenginx: Core Nginx developer announces fork

#427

Post by mikey_p »

bklyn11201 wrote: post #40
reactordev wrote: post #25

Earlier quoted context omitted.

HAProxy is an enterprise load balancer that's available through Red Hat or other OSS Vendor. Nginx is just so easy to configure...

HAProxy is a wonderful load balancer that doesn't serve static files thus forcing many of us to learn Nginx to fill the static-file-serving scenarios. Caddy seems like a wonderful alternative that does load balancing and static file serving but has wild config file formats for people coming from Apache/Nginx-land.

Caddy config is no worse than HAProxy.

Re: Freenginx: Core Nginx developer announces fork

#428

Post by MZMegaZone »

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

That's a whole different discussion - which isn't as dramatic as it is being made out to be.

Other hats I wear (outside of my day job) include being on every (literally, every) CVE.org Working Group and being the newly elected CNA Liaison to the CVE Board. This has been a subject of discussion and things are a bit overblown right now, IMHO. Some of the initial communications were perhaps not as clear as they could have been. But it isn't going to be every kernel bug being a CVE - not every bug is a vuln.

I'm also one of the co-chairs for the upcoming VulnCon in Raleigh, NC. Just a plug. ;-)

Re: Freenginx: Core Nginx developer announces fork

#429

Post by dang »

687m786m78 wrote: post #75

It is scary to think about how much of web relies on projects maintained by 1 or 2 people.

We detached this subthread from https://news.ycombinator.com/item?id=39373804. Nothing wrong with it (well, it's a generic tangent but not a nasty one), but I'm trying to prune the large thread.

Re: Freenginx: Core Nginx developer announces fork

#430

Post by MZMegaZone »

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…

Exactly - this very question came up. And pretty much everyone looked at me as I'm the one who sits on every CVE.org working group (BTW, the CVE rules are currently being revised and in comment period for said revision) and I explained exactly that - just because it is experimental doesn't mean it is out of scope.

Also, something that keeps getting lost here, the CVE is NOT just against NGINX OSS, but also NGINX+, the commercial product. And the packaging, release, and messaging on that is a bit different. That had to be part of the decision process too. Since it is the same code the CVE applies to both. This was not a rash decision or one made without a lot of discussion and consideration of multiple factors.

But one of our guiding principles that we literally ask ourselves during these things is "What is the right thing to do?" Meaning, what is the right thing for the users, first and foremost. That's part of the job, IMHO. Some vendors never disclose anything, but that's not how we operate. I've written a few articles on F5's DevCentral site about this - "Why We CVE" and "CVE: Who, What, Where, and When" are particularly on topic for this, I think.

Post reply on HN