I would say that's actually a misfeature as it requires too many additional filesystem lookups to fulfil requests.

Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.

Does not Microsoft's IIS also have that with web.config files?

Eh. You can use .htaccess in nginx too. I use that everyday.

Ah yes, htaccess. Another lovely source of security bugs for the past 30 years and may it continue to bear skiddie fruit for another 300.

Its model is fundamentally flawed precisely because it was based on the fundamentally flawed PHP model (website assets and code are stored and hosted from the same webroot). This allowed for shared hosting to exist but containers and reverse proxies are a far better way of organising such sites today.

The fact that in other webservers the server's configuration is configured through its configuration file and not the content of its webroot is a feature.

PHP can go to hell. My hair is gray because of it. Nginx is superior, and I can get anything imaginable done with config files. And not to mention, it's much faster.

i mostly use nginx lua to patch on some feature i had even on bare Apache, let alone all the core modules.

Exactly the same for me! I could switch to Nginx, it's one prompt away probably, but why?

nginx has that too https://blog.nginx.org/blog/native-support-for-acme-protocol

One should stop using SAML anyway as that has its own collection of problems. We learned a lot about problems with cryptographic protocols in the last 30 years that cannot be fixed in SAML.

HTTP/3 was the real mistake. It basically reimplements TCP on top of UDP and from my testing (at least the existing implementations) it generally performs worser then HTTP/2. Even when testing on somewhat a bit lossy connection.

You'd think they'd have an LLM reviewing this by now. On the up side, it is refreshing to see good ol' human error still around on the surface!

IIRC popular apache/php platforms such as cpanel, official wordpress docker container image, etc use mpm_prefork by default.

[dead]

Another comment says it has a CVSS score of 9.8 which means CVE, easy to exploit, and an exploit gives LOTS of access.

Before we get too whiny about "it's only memory corruption without any RCE PoC", let's wait until the CVE is unembargoed.

But it's not a given that memory corruption is exploitable as an RCE specifically. I thought to call something an RCE you need a working exploit?

It was a comment unrelated to this vulnerability

If I understand correctly that only affects reverse proxy chains, which people might just not have. Or not have in a way that is vulnerable to that?

I guess it makes sense that "the cloud" moves to it, but beyond that, it might be fine?

That's crazy high.

One of the core claims of the language is data race safety because in safe rust, no memory location can be written by two or more owners at the same time. (see https://doc.rust-lang.org/nomicon/races.html for a more detailed discussion) Consequently, the kind of memory corruptions that this vulnerability seems to exploit are not possible in safe rust. Now, we don't know if a hypothetical rust-based apache implementation would have reached for unsafe in this context or done any other wild thing, but it's fair to assume that the likelihood of an exploitable RCE through memory corruption trends towards zero in programs written in Rust.

The details I've seen are too sparse to say with certainty, but it seems like the issue is concurrent access to the same value through a pointer.

In particular it's `req` in the function with this signature:

    static void assign_headers(request_rec *r, const h2_request *req,
                               int no_body, int is_connect)

The fix being:

                - apr_table_setn(req->headers, "Content-Length", "0");
                + apr_table_setn(r->headers_in, "Content-Length", "0");

My read on this is that `req` is meant to be a readonly value in this function, which is why it's marked `const`. And being readonly, it would be safe to access concurrently. However, someone accidentally wrote through this pointer.

In Rust this would've been `req: &h2_request` and the accidental write wouldn't have been possible (barring interior mutability). Even with interior mutability there is no thread interleaving during the write, which happens through a `&mut h2_request` probably obtained through a lock.

> > a concurrent execution race condition within the assign_headers() function when handling shared resources [...] can corrupt heap memory to achieve arbitrary code execution (RCE)

To my understanding, in safe Rust to share between threads the compiler will require something like Arc<Mutex<...>> - which prevents unsynchronized access or freeing while another thread is still using it.

They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.

https://xin.dev/blog/multiple-nginx-vulnerabilities/

Well there's HTTP/0.9. Can't get much simpler than that.

Depends on exactly what it is that a project is objecting to. For example, here's Nura:

> AI tools have several ethical issues. They require an unreasonable amount of energy[1] and water[2] to build and operate, their models are built in part with heavily exploited workers in unacceptable working conditions[3], usually without consent from or compensation for creators of the source material[4] and oftentimes causing DDoS attacks against FOSS infrastructure in the process[5] (which in turn force the deployment of challenge-based protections and increase cost and complexity of self-hosting for everybody[6]). Furthermore, they are being used to undermine labor and justify layoffs[7]. These are harms that we do not want to perpetuate, even if only indirectly.

( https://docs.nura.eco/policies-and-processes/development/ai-... )

If you really believe that AI tools are automatically unethical because they destroy the environment, harm workers, and constitute an attack on FOSS infrastructure, then it doesn't really matter how the tool is being used. If you just don't want to see code quality decline, then it's probably not a problem.

> Depending on the context and content, I tend to be against AI pull requests that haven’t been edited by a human.

I've seen on a few open source projects I follow the 100% AI patch with notes to the effect of "I haven't compiled let alone tested these changes but AI said it's fine and my cursory glance agrees".

Like come on - I'm not going to judge using AI to make a useful change, but at least put in more than zero effort.

cough Zig... cough

> No LLMs for finding bugs.

same reason i'd imagine that one might have wanted medical assistance be denied to covid deniers who inevitably did contract covid, and started experiencing the FO part of FAFO: retribution and consistency

because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)