NGINX Freed From Its Corporate Overlords
Vložit
- čas přidán 19. 02. 2024
- For a long time now NGINX has been owned and operated by a corporation called F5 and one of the core developers finally snapped and decided to fork the project into FreeNGINX.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Nginx Repo: hg.nginx.org/nginx
Announcing FreeNGINX: freenginx.org/pipermail/nginx...
FreeNGINX Website: freenginx.org/
Nginix Website: nginx.org/
CVE 1: nvd.nist.gov/vuln/detail/CVE-...
CVE 2: nvd.nist.gov/vuln/detail/CVE-...
Ars Technica Website: arstechnica.com/information-t...
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Nginx #linux #OpenSource #FOSS #web #webdevelopment
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation. - Věda a technologie
One of the big points in the "Why not assign it a CVE?" is because a lot of customers are "corporate". Thes have policies that make no sense, written by people who mean well but don't know what they are doing. These are the people who run automated scans against their RHEL servers, see that some version number was reported as too old and then freak out because they think they're going to get hacked.
By assigning this a CVE, they'll demand some form of security patch applied, and it'll be a lot of work for a lot of people, to "fix an issue" that isn't even an issue, because they don't use experimental code in a production system.
This is such a good point and couldn't be more true
Correspondingly, one reason to actually issue it is so that you remain in control of messaging and communications regarding it.
If you are a CNA for your product, and someone reports a vulnerability in that product to you, and you refuse to assign a CVE because it's only in experimental code, the reporter can go above your head and get someone else to assign the CVE. Now, you still have to deal with the CVE, but you also have to deal with an entirely different organization to handle communications regarding it, because it's that CNA that handles it, not yours.
(Yes, they would have to argue that the rejected vulnerability is in fact a vulnerability, but in this case, that can't really be disputed: the issue in question was absolutely a vulnerability. The only thing in question is whether or not it actually affected any production environments.)
This is exactly what happens at my workplace. They wanted to wipe my work laptop because I had an old project on it that I was not using or running in any way and that obviously had an outdated dependency
As someone who had to deal with oval policies for rhel on nexpose, so true. Having a fucking x server is considered a weakness. Literally how.
Ah, yeah, I ran into this at work. Whatever scanner our security people used, detected our nginx version number w/o the distro patches. So they ran to me screaming at me that I run EoL webservers, escalated the issue to the moon at the same time. And I'm like "my brother in Christ, please reconsider your purpose in life, do you even Linux?" So to satisfy idiotic corporate policy we ended up adding a security exception to a fuckton of things, to avoid considering properly patched distro packages as "vulnerable" but at the same time essentially making the policy-mandated "security scans' meaningless. But at least they kept the entire engineering busy for 2 weeks. Good job.
lost opportunity to call it NGINY
Or how about nginTwitter ?
eNGINeZ
TonicNGIN
@@sunnymishra1057lmao
incrementing a letter led us to having x11 instead of w11
>one of the core developers finally snapped
"some of you guys are alright, don't ssh into the webserver tomorrow"
i don't understand the joke, what could they do?
@@HyperboidIt's just another version of "Some of you guys are alright, don't come to school tomorrow"
When you've gone from a paid developer with a voice to an unpaid dev without one, I can see it wouldn't take much to say "fuck it" and just fork.
At least he got well paid by f5 for taking over nginx
That CVE disagreement wasn't the only thing for sure.
Oh 100%, there's no way this was enough for one of the oldest and original members of the project to leave. There's all sort of unsaid signals that point to a degradation in their relationship to the point that he even decided to use the name for the fork, trust me, that's not by coincidence.
Yeah, this is a normal kind of corpo drone interference that happens every other day in a project. Usually when some suit is aiming for a promotion
QUIC is pronounced "quick". It is the replacement for TCP that HTTP/3 uses at the transport layer 🙂
If the code is in the shipping release binary, whether its enabled by default or not, thats production code in use. If you dont think the feature is ready yet, then dont merge it; use an opt-in nightly build channel for testing it instead.
My question is why does f5 ship experimental code to their paying customers?
Why does Google ship the page chrome://flags/ in the stable release of chrome?
Because they want to use these experimental features.
I think an important aspect that a lot of people don't realize is that the whole point to becoming a CNA is to directly control and manage CVEs for your products, and if you reject a vulnerability report(say, because it's in an experimental feature), the reporter can go over your head and get someone else to issue the CVE.
Now, not only do you still have a CVE, but you don't control it! You have to deal with an entirely separate CNA, and get them to handle all the communications and messaging about it, when avoiding that was the whole point of becoming a CNA in the first place.
Didn't Brodie said in the video that if you're CNA for a project you own, only you can issue a CVE for that project ?
@@Winnetou17 You essentially get right of first refusal. If someone wants to report a vulnerability in something you have authority over as a CNA, they have to come to you first.
CNAs are an hierarchy, though. If you refuse to issue a CVE, they can go above you to the next CNA, and make their case there. THAT CNA can choose to issue.
To quote the CNA Rules from the official CVE website(feel free to look it up):
"In cases where requests or issues cannot be resolved by a given CNA, the issues are escalated to the next higher-level Root. Examples of such issues would be a CNA being unresponsive beyond expected timeframes or a disagreement with a CNA over whether or not an issue is a vulnerability."
EDIT: To add more information, if someone were to do this, they would most likely have to provide a reasonable case for why the issue they're reporting is actually a vulnerability, regardless of the response of the authoritative CNA in question.
In the specific case of the issues listed in this video, there is absolutely no room for debate: the issues presented ARE vulnerabilities. As described, they're DoS vulnerabilities that have the ability to shut the server process down completely. The only thing up for debate is whether or not anyone would be affected, since this vulnerability is indeed in experimental, disabled-by-default code that shouldn't be in production. That doesn't stop it from being a vulnerability, though, and someone could make a reasonable case for issuing a CVE.
A CVE for a experimental module, with no known proof of concept or known vulnerabilities, short of terminating (not even hanging) a worker thread, would likely get rejected. Even if you do go over a CNA's head, they get to reply. And all they'd have to say is it's an experimental optional module, and ask for an impact report (which at most they'd claim what, traffic loss maybe? which isn't even reported in the F5's CVE, and it was recorded as a SELF-FIND not downstream).
The reason we don't do things like this, is so we don't put projects that rely on our products, at risk of having to constantly re-evaluate their methodologies. You cry wolf enough, and people will just stop listening.
if nginx is so good why isnt there and nginx 2?!
Because it's not written in JS
The electric boogaloo?
More than half of Clang is experimental and much of that is in active use because many C++17, C++20 and C++23 features are borderline mandatory for good *modern* C++ code, and you can either use Microsoft's MSVC++ compiler which is actually compliant and not experimental, or you use GCC/G++ or Clang which is overwhelmingly experimental/unfinished. I would still like critical bugs in Clang to be reported however...
It depends on the use case, I guess.
Point taken here.
In clang's case, you'd want disclosure of "experiemental" code within a compiler that implements more language standards and proprietary implementations than the number of shades of pink a mantis shrimp can see, squinting.
nginx isn't the same sort of animal, though.
You can also configure your compiling environment to treat all warnings as compiling errors.
@@BrunodeSouzaLino We're talking about CVEs here, not simple coding mistakes.
In an extreme example let's assume that there's a bug in the C++23 implementation where range operators always access memory past range.end() due to a bug in Clang. You can turn on -Werror all you want, the compiler wouldn't notice that it's broken itself
@@insu_nabut the Address Sanitizer can
shipping an experimental feature in a stable binary, yes, it should have a CVE for this reason. disabled by default or not, that code exists in the binary.
_Is_ it in the binary? I might not have been paying enough attention, but my impression is that it's probably not _compiled_ unless the feature is turned on. Is it really a run-time option instead of a run-time one? Because frankly, I don't think that experimental code should be in "release" binaries _at sll._
@@absalomdraconis Yes it's been in the Mainline release for almost a year
@@absalomdraconislol yup, that is the real problem here. the experimental code IS compiled into the stable released binary. it is an option in the config, disabled by default, but only one small config change away from being enabled. for this reason, yes, it should be a CVE without a doubt.
@@absalomdraconis It is enabled with a flag on execution from what I saw in the manual.
This is absolutely my opinion. You shipped it. You take responsibility for it.
open source gives the community a chance to keep alive projects that were severely derailed, but the complexity of them often means it's impossible to maintain them without serious corporate backing
That's more because the vast majority of floss developers do contribute with a vested interested that there will be monetary compensation for them someday in the near future, not because they care about the project or community around it.
@@BrunodeSouzaLino everyone has limited resources, you can spend more time on a project that pays than on a hobby one you work on only when you're done with your job, additionally full time developers are more efficient than someone spending an hour per month on the project, even with best intentions it's extremely difficult to keep a big project running when the main management pushes it into the wrong direction, I've seen many attempts but none of them delivered, including ones backed by another (but smaller) company and full time developers
edit: well, actually OpenOffice and LibreOffice did quite well, but that's basically all I know of such examples
With just what we have here I tend to agree with the company. If something is out in the wild and you see a security vulnerability then cve it to be on the safe side. If you had to download like a canary build or whatever that’s a different story but it sounds like the experimental feature was in the main branch, so cve it.
There already is an update available: freenginx 1.25.4, which *does* have updates.
Now i am wondering, will F5 be merging those bugfixes in their own codebase? 🤔
Does it contain fixes for the CVE bugs? Would be hilarious if it does.
write a distribution licence specifically disallowing F5 and affiliates from using it 😂
@@paultapping9510 If would not be free software if they did that.
One of the principles of Free software is that you are not supposed to discriminate based on who the user/use-case is.
That was why I was annoyed when Microsoft "helped" the city write it's open data license: and limited the fields of endeavor to "legal use".
Not sure how much of a difference it really makes in practice: since no contract/license can explicitly allow "illegal use" anyways.
@@paultapping9510 best he can do is close source it to block that.. since it's bsd
Personally I'd GPL all of my future code to f over all the corpos
@@didikohen455Could as well be, it's not like they didn't want to fix it.
It's just they thought it wasn't wort to file a CVE for an experimental codebase that next week might be changed by 50%
Very important move, software (especially of such importance) must be free! and! community! driven! I will donate a few bucks
He could have named it 'Libre Nginx' though
@@thats-no-moon NginY
@@evoltaocao5078 Engine Why? Dunno man 😀
@@thats-no-moon Nginx is a trademark, you cannot simply use it how you want.
With the word Office I believe it is different, because it's more open, although Microsoft would probably disagree. But they also spell it LibreOffice (one word).
Think before you donate, those few bucks are going to get taxed in a country called russia, so i would urge not donating. Not one penny going in that direction.
Having seen a lot of staff blowups in my day I can guarantee there is a bunch of grievances leading up to this.
Unless it's mental episode that's the only thing that makes sense
Yeah, true that. There is definitely enough high profile cases of workers with mental health issues acting erratically.
What staff? He wasn't staff and afaik there isn't an nginx org within F5 anymore anyway
Definitely air on the side of caution and publish a CVE, just because a feature is in preview doesn't mean companies and people won't use it in production.
Should projects/companies be publishing CVEs for every problematic commit on a development branch?
The point of "experimental" is "we warned you: If you use it, you are on your own".
Having to fix security bugs on in development features as soon as they are discovered would suck up a huge amount of the developers' time, time that might otherwise have been used to fix bugs in the main release (the one that should be in production).
@@alex84632but it's not a development branch, it released code, that is behind config option.
@@alex84632but it’s not on dev branch, it’s an experimental feature in the main production releases.
@@alex84632 There's a huge difference between "This is on a development branch only" and "This is in official releases and users can turn on the feature flag"
I think the issue is that maybe there needs be something like CVEs but for things that are unsupported. Because not using developmental features in production is apparently to much to ask. Maybe EAVEs Early Access Vulnerabilities and Exposures, as opposed to Common Vulnerabilities and Exposures. That way in a case where you want to issue a CVE for something that's still in development, because you know people are using it, you could instead issue an EAVE.
NVE/NPVE: Non-production Vulnerabilities and Exposures
GPVE: General Purpose Vulnerabilities and Exposures
UVE: Unsupported Vulnerabilities and Exposures
All good options for something like this, I think this is a good initiative that would help a lot to keep CVEs relevant and not abuse their use, and also for easier global tracking of other bugs or problems in a more centralized and organized way.
From my experience, I see where the dev's decision comes from. Devs already have to do some form of documentation and have a lot of meetings as the result of agile frameworks. If you can't even work on a WIP codebase that is declared as experimental and is not enabled by default, you shouldn't need to worry about CVEs. I can only imagine that they are a lot of additional paperwork.
What I don't agree on is that his project's name is different enough. It literally has their trademarked name in it. This won't end good for him.
Rename it to NginEZ or nginy like some others suggested, so much potential!
If available HTTPNgin, httpEngine, httpNGN or something like that would be the best IMO.
It still sounds like a web server which ia always important for gaining popularity, and still has a resemblance of "engine" which is the main sound of the name nginx itself.
"Developers" and "documentation" are two words that cannot co-exist in the same sentence or are a real scenario.
@@BrunodeSouzaLino hahaha so true, applies also to other areas, I feel attacked now 😂😂
To be fair, the FreeBSD/BSD precedent will be difficult to ignore for whoever will have to decide about the trademark thing.
I mean, if FreeBSD (and OpenBSD) is allowed and has been for years, why should FreeNGINX be not?
@@qdaniele97 maybe it was never really allowed but they didn't bother with it. Idk how those things work and if you actually have to pursue those cases, even if you don't want to, as a trademark owner
CVEs should be measured and as rare as possible. They are intended to be for things people need to be aware of and deal with asap. Assigning CVEs to every bug would pretty much make them unusable as people will begin treating them with less seriousness.
But they serve the other purpose of being identifiers for bugs. You can ask if something is vulnerable to CCE-XXXX-YYYY instead of "the crash in the proxy module". When is a bug so small that people won't need to talk about it? Never.
@@thewhitefalcon8539 yeah but you don't go around looking for CVEs for beta/alpha software, it's just not how it works.
As long as the code for the vulnerability is not widely deployed in production by default (by the vendor), and there are warnings about experimental options, a CVE is just an inconvenience that WILL make people treat them less seriously if abused.
@@thewhitefalcon8539 ? I think you misunderstand the point of CVEs. We already assign unique names to every bug submitted to a code-base, those are called Issues and we use those every day. The difference is that CVEs are things that are intended to notify end-users of a critical vulnerability that requires action on their part to address (such as applying X patch or updating to at least Y version). Experimental modules are considered unstable and should be receiving regular updates. When users deploy experimental code in production, they understand this.
The bug being referenced here would have been fixed as an issue in the next release as is pretty standard for in-development code. CVEs are more apt for items that have been declared stable and supported. As it is those items that technical staff are not paying attention to.
Again, if every bug was declared as a CVE, they would fail to reliably perform their sole function, which is drawing people's attention to an exploitable vulnerability in code they may be running, and otherwise continue to run for some time. People will treat them with less urgency, and even begin to ignore a pool them. Implementing things like "CVE Day" once a month as if it were any other maintenance task, thereby leaving them potentially vulnerable for WEEKS after a critical vulnerability is disclosed. Desensitizing people to CVEs should be considered extremely harmful and great care should be taken before assigning a CVE for just any odd issue. That goes triple for anything inside experimental software.
Q
O. O. O. J
As soon as code is in a binary feature flaged disabled or in any other way not working but is in release version its CVE time sorry
I don't buy angle that assigning cve is bad because "if customers see cve, they seethe and go away".
Max is a volunteer. He doesn't deal with the clients. That's f5 job. So from information given I side with f5.
Max did mention that f5 broke some agreements but I don't see what he means.
There also was interview on Russian habr, but it doesn't provide further details
I'm impressed that F5 actually had a non-corporate-speak conversation that was respectful about this issue. It's better behavior than I would generally expect from a large corporation these days. Especially since they're in danger of being MariaDB'ed now.
Of course, a sane and levelheaded response is the best way to reduce the chance that happens. But, most places don't realize that. It seems like F5 understood what they bought when they bought nginx.
To me it sounds like F5 is trying to praise themselves for "taking care about security", in kind of a marketing manner. CVEs aren't meant for that. If you're getting spammed with CVEs and they turn out to be hot air, you'll pay less attention over time. And that's not only because they get less important, but also because the rising amount will keep you from doing productive work.
Well, if you attach experimental code into a release, I can't see the harm of adding a CVE for it, so that anyone that wants to use that feature at least is aware of the security implications of doing so. However there may be better ways. You could add this warning in the release notes or in some other way have ngnx alert you if the feature is enabled. At least its not about a company trying to hide something, so I do think this may be a very small thing to disagree this much over. I for one does not see any reason to switch to some other project just because of a few additional CVE's.
One is total transparency, while one is concerned about too much transparency and that might scare people off. Both have a point.
I think the best solution is to just say with experimental code "We're not going to bother with CVEs for this experimental code, nor will we be held liable because you enabled it in your project. Your risk, you make the choice, either way not our problem"
I agree with you in this instance, but many projects leave things marked as "experimental" for way longer than they should.
That's project mismanagement @@alex84632 No other way around it.
Experimental features shouldn't be in production.
No, the best solution is to have release without experimental features, and have another tech-preview release with them. Then there wouldn't be a CVE for release. If feature (even experimental) goes into release it should be processed as any other feature, as it could be enabled with config. And a lot of CVEs are valid only for specific configs.
@@w01dnick He said it wasn't released to begin with, that it was development builds being used by those downstream projects. That means upstream has no responsibility for security issues related to the usage of said features beyond removing/altering the functions enough that compiling with the old name/parameters will cause a compile time error. That is all that is needed for development builds, anything else is overboard. It is only release builds that need CVEs.
@@zxuiji It's been in the mainline release since 1.25.0 so almost a year now.
I think my personal main problem would be why it's common (as in _"Common_ Vulnerabilities and Exposures") for production code to include experimental features. Like, why is my personal use software license for a release version of Acme VideoEditor Pro "as is" and "with no claims to merchantability," but an experimental feature apparently permeates such a sizeable portion of the market that we can't notify users with less extreme measures?
Because you're not paying thousands of dollars for it each year.
I have a sneaking suspicion that this was the final straw in a long line of other straws!
With all respect, the new project will have its own corporate overload, even if they are just one person and seek to have a fully transparent project and everyone likes how it is run.
Non-technical management the bane of developers, designers and architects... the pointy-headed boss is all too real.
I think the dude got tired of working for free for someone else and decided to work for free for himself. And I agree that freenginx is a poor choice for a name
The wording in the original complaint sounds off. “I can no longer control”… its not up to the developers to control a product.
I think he means he no longer has a voice in the company
I get that, but the wording is telling the expectations. I have seen it affect developers. They work really hard on products and start to feel ownership.
As far as CVE's go. This one it rated 7.5, yet is awaiting analysis, and the only fault they could find so far, is a worker process would terminate unexpectedly (not the entire server, just a worker process). I don't see a reason this needed a CVE, let alone a rating this high (7.5) for an experimental module that people have to explicitly opt into and already have an apt disclaimer for in the config/documentation. Which makes sense, because when they filed, they had no idea how to mark their metrics, and left EVERYTHING undefined. Good grief. If there had been a breach of data, or even a proof of concept, I'd change my mind, sure. But this is pre-emptive and did not require such disclosures, and they DID NOT score this properly. This behavior explicitly goes against the CVSS/NIST standards. Whoever they have on the team that suggest this should be done like this, should have to go through FIRST/NIST remedial coursework & CVSS standards. This is NOT how this is supposed to be done.
Keep in mind Maxim doesn't even agree it should be a CVE so take the rating with a grain of salt, CVE rating is not a science it's more of a general feel for a problem
I think creating a CVE for a work-in-progress experimental feature is jusr polluting CVE lists and causing unnecessary panic, if a customer is using experimental features in production that's just a skill issue. I think someone at F5 just wanted to pad a security researcher's CV with a frivilous CVE honestly.
Its been an optional feature in the mainline release for almost a year now, it's somewhat reasonable to assume it's being used or at least tested in production environments already, especially if they know that customers are using it.
It may very well be an experimental feature that they are working on, but if they consider it stable enough to be included in the mainline release then customers testing that feature also need to be informed of security vulnerabilities.
If F5 is so dedicated to providing highly secure software as per their statement then surely the CVE should be, instead of blurring this line of disclosure for corporate policy. Isn't this why you should have stable and dev versions of software... if new options are still in development then they can't be in stable yet until completed/tested.
Call it fringe, r is letter 18, f is letter 6, 6 + 18 is 24 which is x, it contains the letters FREI which in German means free, and the remaining letters come from nginx.
jokes on you, i have automated critical security updates enabled on my server! (of course with notifications so i know why something breaks if it does)
It's actually terrible practice to file CVEs for development bugs, explicitly because people want zero CVE deployments. Dumb managers will see that, freak out, and want to switch stuff based on cluelessness.
This seems a policy failure on F5s part. Experimental features should be explicitly stated to have security supported or not. Seems there are people at the same org who aren't clear which it is. That's actually a bit troubling for how solid the security policy might be overall.
EXPERIMENTAL code is **experimental** for a reason, i completely understand maxim's position here.
People running experimental code in production should expect bugs security or otherwise, if F5 wants to enable that they should have a communication channel for those experimentors, to disclose these type of security issues
Nope. They shipped the code. Experimentation or no. Someone may flip the flag unknowingly.
@@Alan.livingston that still comes down to f5 having a dedicated channel for experimental code ;)
Not reading the documentation is on the user tho
In this instance there would be no documentation because they wanted to just ship a patch and say nothing. I do agree that there should be an entirely different channel for both code and Comms for experimental.
@@Alan.livingston Experimental flags should be something that you have to go out of your way to flip. If the end user can do it by mistake, you have a design problem.
@@Alan.livingston Someone might let a monkey in the server room. Quick, create several articles disclosing the possibility and what to do when a monkey gets in the server room.
The issue I take is that experimental is named like that for a reason. YOU THE CUSTOMER decided to use that, it's YOUR full responsability.
Saying that they shipped the code is a non-issue here. You can compile nginx without http3, so even a rogue/malice configuration change won't affect you, it's not so easy as just flipping a flag.
I think he plans on renaming the name freenginx anyway. Because they will probably sue him and he would agree. That's practically "free" marketing (see what I did here?). And if he never gets sued, that's also good.
If they were shipping this vulnerable experimental code (even disabled by default), then it seems pretty clear to me that assigning a CVE was the right thing to do.
If having CVEs assigned for experimental code is bad, then don't ship experimental code (at least not enabled or with an option to enable it).
It's experimental code. Anyone thinking it has no vulnerabilities is an absolute lunatic. There's a reason it's called EXPERIMENTAL
Changing the name would probably be a good idea though, yeah.
And this definitely isn't the full extent of it.
Did you listen or what? It was told code has vulnerabilities, the point of disagreement is if they should be assigned any specific tag outside of development environment!
It's all speculation. We don't know. We know we don't know. And... we know that.
Create the cve, just assign is a lower risk since it is experimental code.
The subtext here is...why get been bossed around for no pay?
IMHO that should not have been a CVE and those customers shouldn't have enabled a experimental feature in prod. CVE's are a special thing and if they are spammed with experimental feature bugs it quickly becomes the boy who cried wolf problem and you don't have the same reaction to a CVE beeing published. That beeing said cudos to F5 for disclosing it I just think that shouldn't have been a CVE. A blogpost and a mail to the known affected customers should have been the way.
Am I the only one that is leaning towards F5's point of view here?
No. The developer has clearly indicated he doesn't take security seriously - I'm going to stay away from any of his projects.
Eh, I guess? But what I'm hearing is "our competitor is more likely to notify you of vulnerabilities in niche experimental features, while we won't" which is more like a selling point for F5 imo... And yeah, there's no way that's the full story.
Except that it's usually the technical team that is making these decisions. So instead they'll interpret it more along the lines of "This fork is less likely to publish ridiculous CVEs that we will then have to log on at 3am and apply a patch for to satisfy our arbitrary corporate policy despite the fact that we don't even use the module in question"
CVEs aren't just bug reports, if we assign a CVE to every small bug in unsupported code people will stop paying attention
projects should have official channels to report bugs for people who are using unsupported features, and people who are using those features should be expected to keep up with these channels
I do like the idea of a GPL nginx (if that's even possible), but yeah, I don't know who is in the wrong here tbh.
I just hope Maxim changes the license in some way, otherwise I have no reason to use the project...
you would need all of the copyright holders to sign off on that
@@1DwtEaUn ?
@@1DwtEaUnI am not a lawyer, nor do i do i imply to be a lawyer. Anyway, no, you probably can change it, as i see the wording allowing you to change it to a license that has more strict requirements.
Assuming it's BSD 2 license you can fork iit and assign a GPL license to the forked code but that means from then on code could only flow from nginx to freenginx.
This is what happened with the openoffice to libreoffice fork. In that case apache licensed openoffice withered and died and LGPL licensed libreoffice is the thriving branch of the fork.
I doubt freenginx would do this since then the BSDs might not ship it in core though that hardly matters anymore.
My bet is on staying with bsd type licence since they need to have code flow in both directions.
You can also see this in bsd kernels. They have to clean room write every driver so fall further and further behind linux every year.
@@noname-ll2vk I think it may be the 2-clause BSD.
* Copyright (C) 2002-2021 Igor Sysoev
* Copyright (C) 2011-2024 Nginx, Inc.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
I take when we have things that have specific words with specific meanings and those get ignored.
Case in point, having EXPERIMENTAL code. What more do you need to be told to not use this in production, and if you do, do it at your own risk ? Experimental code is so you know what's coming, to be able to work with it and test it, not ship it to production.
To the folks saying that "well, they shipped it, so it's their responsability", I disagree, at least on this particular case. Nginx is opensource and you can compile nginx without http3 (omit --with-http_v3_module), so you can have it without experimental code at all. You can have it removed (not just disabled) at a binary level. So you can be VERY EASILY shielded from "oh, someone just flipped a flag, by mistake or intent". Also, F5's point was that they know people/projects/companies that USE it, not that they simply might have it in the binary.
I understand F5's position here, and I can't really blame them that much, but I do think it's just bad practice and it incentivises bad practice in general, and should be avoided. So I'd be happier if they didn't go the CVE route, but using other means of communication.
I'd vote, if I had one, to rename the freenginx project to webx.
Can somebody who is in the topic tell me why Nginx is so popular? I mean its a Webserver. Why not use Apache or Lighttpd? Not to shit on it, I genuinely don't know.
NGINX is incredibly fast as a static file serving web server, is small and flexible. Also it is incredibly easy to use as a proxy.
Work the first day with Apache and Lighttpd, and the second day with nginx. You'll learn quickly why most have switched to nginx or even alternatives.
Nginx uses a M:N thread model, meaning that it uses multiple threads and each thread executes in a cooperative multitasking way. This makes it push each CPU core to 100℅ and also gives it the ability to serve 30,000 requests per second on a 2 vCore 2GB server.
Apache has a worker pool of (usually 4) processes. It queues up each request and dispatches it to a worker. That worker only processes one request at a time. Apache gets overwhelmed very fast, it can only handle a few hundred requests per second on the same hardware.
The caching and proxy/reverse-proxy capabilities are also very neat. It basically gives you a lot of speed and all the features you'd want for a startup web business without having to reach for a CDN and what not
It's quick and easy to setup vs Apache despite its stock limitations so gained a reasonable amount of market share early on against the threat of having to support IIS in house, and often has features that even if experimental still (HTTP/3 support is related to the CVE in this video in fact) the others lack. End of the day it's really just a case of "we've been using it nearly 20 years we're not changing now", and I can't even blame folks for that learning a new stack is a PITA.
@@cericat I thought nginx was still pretty well regarded. If you had to start from scratch, what would you learn instead?
smell the money f5
I have to agree with the dev, if I'm on schedule I'm on schedule goddammit, stop complaining my code isn't safe or ready when I just put the cake in the oven
I didn't know F5 owned it.
Day 3 of asking for a video showing how to fixing battery life on linux.
more issues (less significant): YT videos and slow personal hotspot internet.
You can tell who is a developer and who is the management defending themselves. Getting to think and defend yourself is a luxury for the internet responses not when your boss is shitting on you in the office.
This feels vaguely familiar to the MultiMC drama, except the dev's response was way tamer. At least he didn't liken his employers to literal rapists.
In that case everything was public so it was a lot easier to come to a conclusion here there's clearly more going on behind closed doors
@@BrodieRobertson Yeah it was just a funny reminder I had, to me it doesn't seem like that CVE was the only reason either. Maybe it would've made more sense if I compared it to the Audacity drama instead, even though that was also public but we didn't knew back then what Muse acquiring it would result on later.
LibreNGINX would probably been better, or maybe NGINlibre.
This CVE vs no CVE issue is, probably, just a reason good enough to present to the public. Or maybe a "last straw". The man was working for free on a project that the corporation was profiting from. The corporation probably didn't want/didn't have the resources to relocate their core developer to... let's put it politely... a less controversial country. Or the developer didn't want or couldn't move (there can be multiple reasons why). The result was the same - the developer, while living in one of the most expensive cities in the world, was working for free or almost for free for a project, where others were getting money and making decisions, and he probably became sick and tired of it.
NGINfX
NGINXf
Server got canceled because I forgot to pay, nothing to update :)
Ngin+
Let’s hope the fork is quickly adopted throughout the multiple Docker images that used NGINX so far.
You're telling me it's not pronounced "nuhjinks"?
No, it's pronounced as /ŋiŋks/ or better read it as /ng/ sound + inks (plural of ink).
You're welcome.
@@Nzyth based IPA transcription. But have you considered /ɳʁ̥.c͡çʼʌĩɴqð/?
NixOS video WHEN>????? WHEN!!!!
ExgineN
Interested content you have Brodie, i say forks? NGINX is viable for production, the guy is in russia a country which I consider the enemy of the west, so i dont think that developer will do any good with a fork.
This isn't just about CVEs I don't think -- but that's just the straw that broke the camel's back.
IMO the project will, sadly, not get much traction -- There's simply much more money and corporate inertia behind nginx proper. However, I think it's totally unfair how so many open source developers in Russia have essentially been exploited for their knowledge without proper renumeration because of the war. If these devs were simply fired it would be different. but companies like F5 wanted to look good for "cutting ties" with Russia while still taking advantage of the Russian devs for free.
Whatever your view on sanctioning Russia, we can agree that this is wanting to have your cake and eat it. I'm glad Russian devs aren't willing to work for the west for free just to suit their bosses' virtue signalling.
I personally hate how nginx works now, because it assumes SO MANY defaults on you, enabling all kinds of crap, even when you just wanted to share folder with files. I just can't trust, at least, how a lot of repo builds are configured.
NGINX has a few pretty simple features just missing from anything but the paid version, one I recently dealt with being brotli compression. It’s possible to compile in through third party modules, but distros and F5 themselves don’t distribute it like that unless you pay. If this project supported the paid NGINX features it would save me much time!
Pretty much any time I see a CVE brought up, it's because that CVE created a ton of extra burden without creating any security benefit. So I definitely get the impression that people need to be judicious about making them.
Because in other cades, it's just an identifier attached to the security update, e g. remote code execution through image metadata on gitlab had CVE, but it's not prominent anywhere.
Ultimately, it should be only identifier so everyone knows what is being talked about.
Idk man ( didn't understand a single thing). Still Rice is superior.
so he wants to make a fork that doesn't report as many security vulnerabilities? lol...
Guy was just salty about something else and he forked it out fo spite.
I'm drunk, may the goddess bless y'all.
I believe in an ideal world, CVEs for experimental code is correct and people just treat CVEs as CVEs instead of as gospel
If you can fix CVEs in the experimental branch, why not simply merge them to your working branch?
In an ideal world, people wouldn't use experimental code in production, which would make issuing a CVE pointless.
@@t1m3f0x You need people to use experimental/beta releases so you can get early feedback or the version and where else would you actually use them if not in a production env. Using a dev env would defeat the entire point.
If an experimental feature is merged to main, it's to be expected the feature was accepted as stable-enough with some rough edges
Another fork.. we've seen so many over the last few years, I just want companies and devs getting along.
I bet Wayland will follow this or next year.
Why would Wayland be forked? It's not owned by any company
@@flarebear5346 Because of the many disagreements between the people involved in the project and devs they need to work with (KDE/GNOME/..). The Wayland people have a clear goal, but it doesn't seem to always work with the current DE's.
I do agree about Wayland being careful, but KDE is pushing a lot to have more protocols for example. So I'm kinda worried about how things will be in the near future.
@@flarebear5346 maybe because of the people obstructing the adoption of a protocol that would let windows tell the compositor were they want to be created?
CVE for experimental code is.... mental.
First
its because NGINX is a Russian Project. That is the real Reason behind the drama.
But... F5 is an American company... and some developers happen to be Russian, but not all of them (or even most of them). That's like saying that Windows is an Indian project just because many Indians happen to work there, you're braindead
He shouldn't name the project "freenginx", not because of the legal part, the name is just horrible
well F5 did close its moscow office becase of the sanctions right?
thats one of the core problems with Nginx being a corporate project and not a community driven one
why the fuk you should kick your core devs?
Given a choice NGINX from corporate entity or NGINX fork run by russian hacker I think I will stick to corporate entity...
I guess you don't know who started NGINX
@@BrodieRobertson who started NGINX isn't relevant, what maters to them is who currently owns it.
Maxim had been a core developer for years, they had an office in Moscow until 2022, it's always been a Russian project it's just owned by a US company. It not being a Russian project is the rarity
@@BrodieRobertson I'm aware that he is an original creator, however under corporate ownership at least someone was reviewing pull requests (I hope). What will happen with freeNGINX when one day sad man will visit Maxim and offer him a proposition that he can't refuse? Unfortunate Russia is totalitarian regime right now.
@@maciej-36It's being FOSS that makes the project trustworthy, not being corporate backed. If anything corporations are much more likely to do shady things. I swear you people can't read the word russia without shitting your pants
Another dev stuck in Russia making the news...
Sorry, but doing CVEs for experimental features/code branches/whatever, is literally Software Wokeness. If you as a client are able to consciously turn on a EXPERIMENTAL feature of a piece of software, You as a client are PERFECTLY AWARE this is a potential death pit, and could seriously jeopardize your entire setup, ESPECIALLY running it in production environment. Instead, Clients turning to experimental features/branches should run quietly and report back any bugs and/or problemsolving procedures back to development. IF - otoh - you as a client is NOT aware of the potential risks of running experimental software in a production environment, you are deeply incompetent! AND for that reason alone, the organization making the experimental feature available, should state a very clear warning and explicit policy on what to expect running said experimental software!
And, to me, this is what this is really about: Did you as the publishing organization made SURE, your customers was aware of the risks, before using experimental features? If not, the organization is deeply incompetent, and must rectify this situation.
He's in Russia, what do you want to do? 😂
while the company is not lol
He also worked on the project for two years without pay. And a lot of the remaining developers are russian. And the original creator of nginx is also from russia. The original nginx website is available in two languages - english and russian. Why do you think that might be?
Now, please explain to me, why do you think their country of birth/residence matters in this case? Isn't Open Source is supposed to be open, fair and based on merit?
@@ruroruro being from Russia doesn't have to do with Open Source, it has to do with the relationship between him and F5.
@@t1m3f0x if that was the intent behind OPs comment, why is it "He's in Russia, what do you want to do?" rather than "F5 is in America, what do you want to do?".
It seems pretty clear to me, that OP implied that him being a russian developer is bad for some reason in this case. I'm not gonna speculate about what exactly they meant in this case, but the general negative implication is quite obvious, imho.
So you are telling me, that a russian guy lost his privileges because his country basically started a war, he got upset and simply forked the project. Would you like to have a guy in your project that may voluntarily or forcibly sabotage the project? I don't think so
The point is that FOSS shouldn't be influenced by corporations but only by the community
nginx is mainly developed by Russians, as seen in the commit history
@@ndrechtseiter A project can be driven by a corporation AND developed mostly by individual programmers. It's about money and influence mainly.
are you a NAFO bot?
The guy literally developed a project for free for 2 years, no privileges included. What the hell are you talking about?
They could do what people did with the FOSS version of DviX, XiVD
XNIGN?