On Wednesday the PHP Foundation published a post titled “Today’s PHP Security Release, and How We’re Strengthening PHP Security.” It drew 692 points and 340 comments on Hacker News, which is a great deal of opinion for one diff. The thread split, as these threads do, into the two available moods: gratitude toward the maintainers, and the suggestion that everyone port their stack to something with a marketing department.
Both moods miss the thing that actually determines whether this release protects anyone.
A Release Note Addressed to the Wrong Audience
Read the title again. It pairs a patch with a governance story — a security release and how we are strengthening security. That pairing is now standard, and it is not primarily aimed at programmers. A modern open-source security advisory is a liability document. It exists so that downstream integrators, hosting providers, compliance departments, and eventually insurers can point at a URL and say: the upstream project disclosed, we were notified, we acted.
The people who need that document are not the people who read the diff. The diff is read by a few hundred specialists and by the security scanners that will flag the version string in a lockfile sometime next week. The document is read by a person in a procurement meeting who needs to know whether the vendor questionnaire comes back green.
That is fine as far as it goes. Paperwork has a role. But it means the ceremonial center of a PHP security release — the advisory, the blog post, the HN thread — is a conversation among the fully staffed, about a commons that is mostly operated by the unstaffed.
The Bottleneck Is Forty Client Sites
PHP’s great virtue and its great structural problem are the same fact: it is the language of the small operator. WordPress runs on it. The web agency with eleven employees runs on it. The church website, the dental practice booking system, the regional furniture retailer’s catalog — all of it runs on it, frequently on shared hosting, frequently on a version someone installed during the Obama administration and has not thought about since.
I put the question to a developer at a ten-person agency in Grand Rapids, Michigan, who keeps roughly forty client sites alive and who wrote to me in a Slack message: “I will get to it Thursday if nothing breaks, and something always breaks. Half my clients think a security update is when I change their admin password.”
That is the whole problem in one sentence. The patch is free. The labor to apply it is not, and the person bearing that cost is not the person capturing the benefit. The maintainers spend their hours on the hard cryptographic work; the actual protection of a dental practice in Kent County depends on whether a contractor with forty accounts has a spare afternoon and a client willing to pay for it.
Meanwhile the enterprise tier — the shops that already have a person whose entire job is vulnerability management — will be patched before Friday. The gap between those two worlds has nothing to do with the quality of Wednesday’s release. It has to do with who can afford to care.
Liability, Not Philanthropy
The fashionable answer is to send more money to the foundations. That is a decent instinct aimed at the wrong target. The PHP Foundation is not going to hire an army of sysadmins to log into cPanel accounts in suburban Michigan. Money sent upstream buys audits and more maintainer hours; the failure is downstream, in deployment, where no grant program reaches.
The more interesting answer is to stop treating unpatched software as a private misfortune and start treating it as a product defect — one with a defendant attached. If you sell a $30,000 website with a content management system and you do not maintain it, the customer currently absorbs the loss when it is compromised. Shift that: a maintenance obligation in the contract, enforceable, with real exposure. Watch how quickly the agency calendar fills up when the failure to patch is a line item in somebody’s insurance renewal rather than a bad Tuesday for a dentist.
Conservatives should like this on paper, because it is tort and contract rather than a new agency. They will hate it in practice, because the defendants are small businesses, not distant monopolies. That discomfort is the useful part. The alternative is what we have now: a voluntary honor system in which the people most able to patch are the least exposed, and the people least able to patch are the ones holding the data.
The Release Is the Easy Part
None of this is an argument against Wednesday’s release, or against the people who spent their week on it. It is an argument about where the credit and the attention should stop.
A patched PHP is a press release and a version string. A protected web is a maintenance schedule, a contract clause, and several thousand small operators with the time and the incentive to do a boring thing on a Thursday. We have gotten very good at the first. The second is the part that 340 comments will not fix.