You've got the detailed technical writeup on one end in the patches themselves, and on the other end you've essentially got the AI and security companies both together (php2shell) and independently with their highly polished microsites and blog posts with attractive infographics and stylized pitch deck looking images.

Every publication on the other side of the detailed technical writeup in the patches themselves wanted to make it into a huge fucking marketing stunt first and foremost, providing absolutely zero added practical benefit or value.

https://www.php2shell.com/

https://patchtheplanet.org/

https://www.wiz.io/blog/php2shell-php-rce

https://calif.io/php2shell/

I initially updated the following php.ini setting and verified that it updated via phpinfo(). I understand this to be only a possible mitigation (see below).

  session.upload_progress.enabled = Off
  file_uploads = Off

  "INI settings alone won't protect you. You need to patch PHP."

I use Apache, and added an htaccess rewrite rule in my base directory to block all requests containing multi-part headers. Rewrite rules can also be added into Apache virtual host blocks. Accepting file uploads are not a critical function of the app in my case. This blocks multi-part form requests before they reach PHP.

  RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
  RewriteRule ^ - [F,L]

I'm continuing to learn about the situation and may take the server offline as I learn more.

The writeup I found here:

https://jackalsyn.com/posts/php-up-2026.html

Content from a couple of my ChatGPT 6 Pro sessions about the issue:

https://chatgpt.com/share/6ad89ea3-b2f0-83ea-9c4c-2ecf5cc24b...

https://chatgpt.com/share/6ad8ad3d-3f6c-83e9-abf0-41da8a0d65...

  The vulnerability was rated 9.2 (critical) out of 10 under CVSS v4.0 by PHP developers,[1] while security firm watchTowr rated it a full 10.0.

Comments URL: https://news.ycombinator.com/item?id=49914962

Points: 30

# Comments: 13

However, as far as what's being pursued, it seems more like wantonly trying to ride a hype cycle without strongly questioning the end-to-end value of new software development approaches or vetting their immediate suitability.

Personally, I think it would be more sensible to take a few individuals or a smaller team(s) and do more isolated/skunkworks experimentation and adopt as justified based on what those people report/experience. The smaller group can adjust faster and iterate/advise the larger dev org about the good approaches/techniques/strategies, and avoid more broad damage/chaos for things that aren't that well thought out.

For more conservative AI use cases like adding to code review, writing low stakes PR summaries, or beefing up security checking, a more global, but still not off-the-rails, approach would be the kinds of things that would make more sense to push more broadly.

This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved.

The cyclomatic complexity metric is touted at each step as a proxy for goodness of design and removal of complexity. However, a weakness of the measure itself is that it doesn't account for the control flow indirection that happens through OO method dispatch itself.

At the same time, Kevlin Henney's talk called "Gilding the Rose" takes the same kata and arrives at a far more sane solution he works up to and reveals at the end.

Short functions used to be hot. Uncle Bob used to proselytize "The first rule of functions is that they should be short. The second rule of functions is that they should be shorter than that." Now emphasizing the benefits of longer functions is pretty trendy. https://github.com/johnousterhout/aposd-vs-clean-code

This industry is pretty idiotic sometimes ¯\_(ツ)_/¯

> - extent to which correctness of solution be easily specified and checked

I don't think most software is like solving a math problem or series of math problems. Algorithmic problems are very narrow and might be more like this though, where an oracle that verifies answers as either correct or incorrect exists beforehand.

The correctness function of most software is how much users want to use/pay for it, which is a pretty fuzzy problem. Since the cost of copying software is effectively zero, software systems also tend to be be unique rather than being exactly like something else, and don't converge to be like another software system but rather diverge.

The prior art point is an interesting one. At least for applications as a whole, there isn't really prior art for a material amount of all the problems/tradeoffs a non-trivial software application embodies. For a todo list app or make a social network project, there's plenty of prior art to be sufficient to build something with an LLM system, but probably not most apps.

That's my initial intuition anyway.

``` In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily evil, but they're not necessary for most of the things we use threads for.

One of the things I like about the browser model is that we only get one thread. Some people complain about that—if you lock up that thread, then the browser's locked up. So you just don't do that. There are constantly calls for putting threads into JavaScript and so far we've resisted that. I'm really glad we have.

The event-based model, which is what we're using in the browser, works really well. The only place where it breaks down is if you have some process that takes too long. I really like the approach that Google has taken in Gears to solving that, where they have a separate process which is completely isolated that you can send a program to and it'll run there. When it's finished, it'll tell you the result and the result comes back as an event. That's a brilliant model. ```

Agree, and I think that's the core of my point.

Not that it's irrational or doesn't make sense to sell tokens for purposes of software dev, but that if tokens were a true game changer for success in software dev, they wouldn't be leading with token sales, the same way they're not leading with token sales for security stuff -- it's more like "Contact Sales".

Something that stands out is that for the strongest use cases, AI companies will prefer to sell the technique as a service rather than its raw output. For use cases where the output is less valuable, tokens are sold. If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.

The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than taking their knowledge and making money in the stock market directly.

12:5712 minutes, 57 seconds on AI coding for real engineers. This has been my most subscribed to course ever. People are going nuts for this. Uh

13:0413 minutes, 4 seconds we're going to have I think around 4,000 4,500 people in there. So, yeah, it's absolutely wild. But if you're enjoying

Matt Pocock https://www.youtube.com/watch?v=mh5XZ-L5SFQ at 13:00

4k x $995 = ~$4 million

During a goldrush, sell shovels.

Comments URL: https://news.ycombinator.com/item?id=48321838

Points: 3

# Comments: 0

Some of the maintenance costs you mentioned are primarily read-only, slam dunk AI use cases. Input from AI to diagnose bugs, trace data flows, and help with reasoning. Tests are something of a gray area in the sense that they are not read-only but they don't affect the logic of the app itself.

The "write" use cases (you mention refactoring and the author seems to primarily focus on writing code) is where the author's point seems to be primarily aimed at.

Definitely agree on the read-only improvements to maintenance. Those are unquestionable slam dunk, high value improvements.

Unfortunately, maintainability is simply bucketed as a "non-functional" requirement.

Maintainability (and similar NFRs) should actually be considered what preserves and enables the delivery of future functional requirements -- in contrast to framing non-functional requirements as simply "how" the software must do what it does vs. the "what"/functional requirements that "actually matter".

From that standpoint, if a steady flow of features/improvements is important for a project, maintainability isn't really a non-functional requirement at all, and amounts to being a functional requirement, in practice, over anything except the shortest of time horizons.

Comments URL: https://news.ycombinator.com/item?id=36488070

Points: 58

# Comments: 18

Also good: "CASHUP" - "Career Advancement over Suitable Technology in the Use of Programming."

TAH syndrome, which stands for "Technology Advancement Hyping."

Comments URL: https://news.ycombinator.com/item?id=35847224

Points: 2

# Comments: 0