341–350 of 501 posts
>freenginx.org IANAL, but i strongly recommend reconsidering the name as the current one contains a trademark.
They could take the Postgres naming approach. Ingress was forked; the Post fork version of Ingress was called "Post"gres. So maybe name this new project "PostX" (for Post + nginx). Though that might sound too similar to posix.
Earlier quoted context omitted.
While I may share the general sentiment, there’s a freaking lot of “Russian software” out there which you may be knowingly or unknowingly use. There is JetBrains, for example. But there is also core-js which is a little polyfill library being used by like way more than half of high profile websites. Also written by a Russian national. If you excise all contributions by Russian nationals to PostgreSQL or the Linux ker…
Regarding Jebrains - both owners have renounced their Russian citizenship and are now citizens of Cyprus: https://www.forbes.com/profile/valentin-kipyatkov/ Plus the HQ is in Prague, Czech Republic: https://www.economist.com/europe/2021/05/27/russia-puts-the-...
Earlier quoted context omitted.
Because Windows does not have a good SSH implementation and PuTTY has always worked extremely well for me as a serial and SSH terminal (also, it starts up instantly and never crashed on me). Are there any better alternatives?
Many people I know just use SSH from the WSL CLI.
Then there's things like x11-style copy-paste.
Earlier quoted context omitted.
We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.
[flagged]
Earlier quoted context omitted.
Why wouldn't he want CVEs assigned?
I haven't read the content of the patches to understand the impact of the bugs, but from my own experience [0] I can suggest a few reasons: - CVEs are gold to researchers and organizations like citations are to academics. In this case, the CVEs were filed based on "policy" but it's unclear if they are just adding noise to the DB. - The severity of the bug is not as severe as greater powers-that-be would like to think…
Earlier quoted context omitted.
SSH was a replacement for RSH, not telnet.
Where does this idea come from? I see it repeated a lot, but it's not correct. rsh was common on internal networks, but almost never used on the wider Internet. telnet was everywhere all across the net. ssh was a revelation and it replaced telnet and authenticated/non-anonymous ftp primarily. And also sometimes rsh, but less importantly.
The command line options were almost identical for an easy switch. ssh even respected the .rhosts file! Last time I checked, that functionality was still in place.
Both the rlogin-family of commands and the telnet/ftp-family were in use across the Internet, certainly in cases where Kerberos was used. I would think telnet was more common, certainly so outside the UNIX sphere of influence, but things like Kermit also existed.
They all got SSL-encapsulated versions in time, but Kerberos solved authentication for free, and for the simpler use cases ssh had already taken over by then. And in the longer run, simple almost always wins!
Earlier quoted context omitted.
Did I miss something regarding that Maxim didn't want CVEs and disclosures? I was not aware of this. And F5 are the ones wanting to add the CVEs (as happened in the announcement which was released an hour earlier)? I could have sworn that I've read about Nginx CVEs in the past.
Well it seems he didn’t think this particular thing should have one despite the criteria being clear.
In that case I'd agree with his view, though I think his reaction is a bit over the top.
[0] https://freenginx.org/pipermail/nginx/2024-February/000007.h...
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.
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.
> [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
> contradicts our agreement. And, more importantly, I no longer able
> to control which changes are made in nginx within F5, and no longer
> see nginx as a free and open source project developed and
> maintained for the public good.
The whole drama seems very short-sighted from F5's perspective. Maxim was working for you for free for years and you couldn't find some middle ground? I imagine there could have been some page on the free nginx project that listed CVEs that are in the enterprise product but that are not considered CVEs for the open source project given its stated policy of not creating CVEs for experimental features, or something like that.
To nuke the main developer, cause this rift in the community, and create a fork seems like a great microcosm of the general tendency of security leads to wield uncompromising power. I get it. Security is important. But security isn't everything and these little fiefdoms that security leads build up are bureaucratic and annoying.
I hope you understand that these uncompromising policies actually reduce security in the end because 10X developers like Maxim will start to tend to avoid the security team and, in the worst case, hide stuff from their security team. I've seen this play out over and over in large corporations. In that sense, the F5 security team is no different.
But there should be a collaborative, two-way process between security and development. I'm sure security leads will say that they have that, but that's not what I find. Ultimately, if there's an escalation, executives will side with the security lead, so it is a de facto dictatorship even if security leads will tend to avoid the nuclear option. But when you take the nuclear option, as you did in this case, don't be surprised by the consequences.