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

151–160 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#151

Post by kelnos »

MZMegaZone wrote: post #106
tptacek wrote: 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…

Oof. Presumably Dounin had other gripes about the company that had been building up? This seems like a pretty weird catalyst for a fork. Feels more like this was the last straw among many.

I get that CVEs have been politicized and weaponized by a bunch of people, but it seems weird to object that strenuously to something like this.

Re: Freenginx: Core Nginx developer announces fork

#152

Post by LinuxBender »

darkhorn wrote: post #142

I don't understand why some people use a Russian software! Especially in this age.

In some cases there are not great alternatives that fit the needs. I have not found anything that matches LFTP Using the mirror subsystem with SFTP and connecting to chroot SFTP servers. It replicates the behavior of rsync in a chroot SFTP-only environment. Only downside is that since there isn't a syncing daemon on the other side, directory enumeration is much slower. File transfers are exponentially faster however as it can do as many SFTP sessions as desired for batches of files or even one big file with the only limit being the bandwidth from client to server.

For NGinx I have been able to make use of HAProxy and Apache just fine. Long ago Apache was slower than NGinx but ever since APR 1.7 and Apache 2.4 there are about the same performance wise. Some here don't like the configuration syntax but I am used to it.

Re: Freenginx: Core Nginx developer announces fork

#154

Post by kelnos »

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!

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.

Re: Freenginx: Core Nginx developer announces fork

#155

Post by nullify88 »

eddieroger wrote: post #88
JackSlateur wrote: post #39

Earlier quoted context omitted.

Lots of people are using haproxy

My org moved off nginx for haproxy after we learned that (at the time, maybe it changed) reloading an nginx config, even if done gracefully through kernel signals, would drop existing connections, where haproxy could handle it gracefully. That was a fun week of diving in to some C code looking for why it was behaving that way.

How did you come to that conclusion? I always believed a reload spawned new workers and let the old one drain off.

Re: Freenginx: Core Nginx developer announces fork

#156

Post by kelnos »

droopyEyelids wrote: post #149
MZMegaZone wrote: post #81

Earlier quoted context omitted.

I think you'd have to ask Maxim. My take is he felt experimental features should not get CVEs, which isn't how the program works. But that's just my take - I'm the primary representative for F5 to the CVE program and on the F5 SIRT, we handle our vuln disclosures.

(not explicitly asking you, MZMegaZone) Does anyone understand why a disagreement about this would be worth the extra work in forking the project? I'm not very familiar with the implications, so it seems like a relatively fine hair to split- as though the trouble of dealing with these as CSV would be less than the extra work of forking.

It probably wasn't. There's likely something else going on. Either Dounin had already decided to fork for other reasons, and the timing was coincidental, or there were a lot of reasons building up, and this was the final straw.

Or he's just a very strange man, and for some reason this pair of CVEs was oddly that important to him.

Re: Freenginx: Core Nginx developer announces fork

#157

Post by anon-sre-srm »

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!

Incorrect. Features available to users still require a minimum, standard level of support. This is like the deceptive misnomer of staging and test environments provided to internal users used no differently than production in all but name.

Re: Freenginx: Core Nginx developer announces fork

#158

Post by Twirrim »

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!

You and I have very different notions of "shipped". It's open source code, it's being made publicly available. That's shipped, as I see it.
Post reply on HN