Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

171–180 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#172

Earlier 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.

SSH was a replacement for Telnet. But any weaknesses at the TTY level is orthogonal to that, right?

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

#173

Earlier 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.

This is an insane standard and attempting to adhere to it would mean that the CVE database, which is already mostly full of useless, irrelevant garbage, is now just the bug tracker for _every single open source project in the world_.

Re: Freenginx: Core Nginx developer announces fork

#174

Earlier 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.

yes busybox httpd or civetweb is even smaller, both around 300kb.

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

#176
post #104

Earlier 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.

this problem -- great forward compatibility of the web -- has been taken care of with application layer encryption, deceitfully called "transport layer" security (tls)

Re: Freenginx: Core Nginx developer announces fork

#177

Earlier 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?

I wonder how many of these things that are just coasting are gonna have issues in 14 years.

Re: Freenginx: Core Nginx developer announces fork

#179

Is this what the security disagreements is about https://mailman.nginx.org/pipermail/nginx-announce/2024/NW6M... ?

Yep. Maxim did not want CVEs assigned.

> 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.

Post reply on HN