TekMol

There is a strong indicator that this is true:

There is no news about hacked websites due to this vulnerability.

If anyone could ask Claude for an exploit, one would expect a lot of PHP sites to be hacked just for the fun of it, right? Like putting a message on some popular website or something.

This is about the code itself. Not about the availability.

Can it really take over 10k additional lines to fix a pointer issue bug like this, where the problem is that the code uses memory that it has freed already?

I wished they had put the tests in a commit on their own so it would be immediately clear how large the patch itself is.

Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?

The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?

I have not seen confirmation that the exploit is for the bug that is going to be patched.

It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.

Many here call for an earlier release of the patch.

But it is not clear if releasing the fix early would make the damage smaller or larger.

Having the patch probably makes creating an exploit easier. So the number of attacks would increase.

There is no way to coordinate the whole world on an earlier time. I would guess the number of people who have to patch their instances is in the hundreds of thousands.

Everybody who actively watches the topic already has the option to shut down their instances.

So ringing the bell and getting as many people as possible to shut down their webservers now and patch at 14:00 might be the best in terms of damage minimisation.

By the way, it is not enough to just "shutdown -h now" and then later restart and "apt update && apt upgrade". The moment the machine comes back, it can get hacked. So you should make sure the webserver does not start after the next boot. For Apache this would be something like "rm /etc/systemd/system/multi-user.target.wants/apache2.service" and then after patching recreate the symlink via something like "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service".

What about servers that run PHP from the Debian repos?

How fast will the repos be updated?

Swift, Shell, Python and Objective-C

Does one need 4 programming languages to draw something on a mac?

I still don't get how copying copyrighted content to your own website and then asking for donations can be a legal business model. Nor how it can be morally justified.

I get that many people like such an archive to be around for consumption. Me too. But, keeping emotions aside, I can't find a justification to violate the rights of creators.

I'm sure many people here will have the knee-jerk reaction to immediately downvote this question. But I know there are also thoughtful people on HN. If some of you have ideas about the legal and moral justification for archive.org's actions, I would like to hear them.

I never understood why a program installed in Flatpak is not just a directory on disk.

When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.

The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.