They want performance at all costs and apparently that includes avoiding anything from libc and making a whole bunch of hand-rolled sketchy performance-oriented code full of free lists, arenas, lock-free data structures, custom threading, etc. Lots wrong from glancing over it.
Conversation
I don't generally file bugs in software that I don't use. Have no plans to use NGINX Unit and ideally in the long term there will be something better than nginx.
nginx itself is pretty stagnant even though there's a lot to improve when it comes to latency and safety/security.
1
1
Are there any companies that use NGINX and have a bug bounty program? Because NGINX is practically *the* static file server nowadays, and is used as a reverse proxy by Cloudflare too.
1
1
nginx itself is a lot more mature and far less ambitious than the newer NGINX Unit. It still has a similar approach to rolling everything themselves but they aren't trying to provide nearly as much functionality in their traditional / legacy web server vs. the new web/app server.
1
It's hard not to get the impression that they increasingly see nginx as a legacy product and don't find it to be a particularly compelling place to invest resources. They're slowly working on HTTP/3 support but it's pretty stagnant and even small improvements tend to rot.
1
At least as an outsider, my impression is that NGINX Unit is intended to displace many of the use cases. It moves to a far more declarative configuration model and has proper dynamic reconfiguration via an API and other features normally gated behind the NGINX Plus product.
1
It's not really a complete replacement for nginx as a static web server and reverse proxy right now... but it seems like that's the intention, and that they're a lot more interested in NGINX Unit performance, latency, scalability, etc. going forward than the traditional project.
1
The code style and NIH approach in both is pretty much the same. They write highly optimized low-level code to the extreme across the board, with performance clearly as the top concern far above correctness/safety/security.
1
Boggles my mind that github.com/yandex/gixy/bl is an issue for nginx and it stresses me out dealing with the configuration since so much of it is a trap allowing cookie injection or worse via URLs. I don't get why they don't at least sanity check the input to those directives.
1
nginx has location blocks with regular expressions including captures but if you use those directly and pass the captures to regular directives like return, you're permitting attackers to inject HTTP headers since location blocks unescape output and directives don't escape it.
You can cause problems other ways, but that's the typical way. They basically invented a whole completely unnecessary class of vulnerability simply by using the configuration in the obvious way. Other stuff like Apache has even worse problems in some ways. Still inexcusable IMO.
1
nginx is the classic example of software that I use reluctantly because it's still the least bad option for what I need. nginx itself (but seemingly not NGINX Unit) is an open core project and seems to be in this phase of not doing anything without a big corporation paying them.
1
1
Show replies