Freenginx: Core Nginx developer announces fork
171–180 of 501 posts
Re: Freenginx: Core Nginx developer announces fork
#172Earlier quoted context omitted.
That only helps if it stays static. For example, if the Linux TTY interface was unchanged for decades to such a degree that nobody worked on it, but then had a vulnerability, who would be able to fix it quickly?
Perhaps someone with more knowledge can chime in. But, my impression is that there are vulnerabilities with TTY, it's just that we stay educated on what those are. And we build systems around it (e.g. SSH) that are secure enough to mitigate the effects of those issues.
Unless you mean, having thin clients use SSH as opposed to directly running serial cables throughout a building to VT100 style hardware terminals, and therefore being vulnerable to eavesdropping and hijacking?
But I think when we talk about TTY we mostly don’t refer to that kind of situation.
If someone talks about TTY today, I assume they mean the protocol and kernel interfaces being used. Not any kind of physical VT100 style serial communication terminals.
Re: Freenginx: Core Nginx developer announces fork
#173Earlier quoted context omitted.
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.
Re: Freenginx: Core Nginx developer announces fork
#174Earlier quoted context omitted.
I have been using lighttpd which can also host static content and do proxying, on top of those lighttpd supports cgi/fastcgi/etc out of the box as well, and it takes 4MB memory only by default at start, so it works for both low end embedded systems and large servers.
I've recently needed to build a docker image to run a static site. I compiled busybox with only it's httpd server. It runs with 300kb of ram with a scratch image and tini. I didn't compile in fastcgi support in to my build, but it can be enabled.
for tini you mean https://github.com/krallin/tini? how large is your final docker image, why not just alpine in that case which is musl+busybox
Re: Freenginx: Core Nginx developer announces fork
#175Re: Freenginx: Core Nginx developer announces fork
#176Earlier quoted context omitted.
Not the web though
Certainly the web can mostly coast indefinitely. There are webpages from decades ago that still function fine, even that use JavaScript. The web is an incredibly stable platform all things considered. In contrast, it's hard to get a program that links to a version of Zlib from 10 years ago running on a modern Linux box.
Re: Freenginx: Core Nginx developer announces fork
#177Earlier quoted context omitted.
Not that scary when you remember there are some systems that haven't been significantly updated for decades (e.g. the Linux TTY interface). A lot of stuff can just coast indefinitely, you'll get quirks but people will find workarounds. Also this is kind of why everything is ever so slightly broken, IMHO.
That only helps if it stays static. For example, if the Linux TTY interface was unchanged for decades to such a degree that nobody worked on it, but then had a vulnerability, who would be able to fix it quickly?
Re: Freenginx: Core Nginx developer announces fork
#178Note for some reason Maxim chose to link to http://freenginx.org , instead of https://freenginx.org
Re: Freenginx: Core Nginx developer announces fork
#179Is this what the security disagreements is about https://mailman.nginx.org/pipermail/nginx-announce/2024/NW6M... ?
Yep. Maxim did not want CVEs assigned.
... to this specific bug in an experimental feature.
Originally I read your comment as Maxim doesn't want to use CVEs at all.