Half the clock

A test held back for a week. A security release pinned to the minute. Most of a bug bounty moved into public GitHub issues. Within a day of each other, three of the most widely deployed open-source projects changed how they ship security fixes, and on the surface they went three different ways.

Mozilla asked Firefox developers to land the tests for sec-high and sec-moderate fixes as a separate patch, no sooner than the Tuesday after the fixed release ships. PHP, after purported details of two bugs leaked, told every user to be ready for patches at 14:00 UTC on Wednesday, for two vulnerabilities rated 9.2, and kept the right to ship earlier if the details go public. And curl announced that from October 26, reports it rates LOW or MEDIUM go to public GitHub issues instead of its private HackerOne queue. Over the last few years, that has been more than 90% of what arrives.

The pressure behind all three is the same, and Mozilla put it in the first sentence of its note: "As AI keeps improving, our security policies are changing in response."

A published fix used to close a vulnerability's story. Now it opens one. A model reads the diff, works out what it closes, and either writes the exploit or goes looking for the sibling bug the fix missed. Sansec told Ars it expects mass attacks on PHP "to start within 15 minutes of the release." The three policies differ because each project can do something different with the time a secret buys. A secret only buys time if somebody spends it installing the fix.

Mozilla can spend it. Firefox updates itself by default, so the week a test stays private is a week the fixed build spends reaching machines without anyone booking a maintenance window. The test is also the most legible part of a patch, a reproducer with the assertions already written. Holding it back costs Mozilla little and slows the fastest reader.

PHP can't hide much. The moment it ships, its fix is source code anyone can diff, and it reaches users through distro packages, container images, hosting panels and admins who schedule downtime. That's an estimated 1.3 million internet-connected hosts, by one researcher's count. The project has no update channel of its own to spend a secret on. So it pulled the one lever a source project has: it told everyone the minute. That turns a fifteen-minute exploit race into a fifteen-minute install race, which the attentive can win.

A secret only buys time if somebody spends it installing the fix.

curl went the other way because for most of its bugs the secret wasn't buying anything. Much of its install base sits in devices that won't see a new build for years, if ever, so a quiet patch does little to shorten anyone's exposure. And the fix gets read either way. Daniel Stenberg describes what happens now each time curl publishes one:

If that army reads the fix regardless, it might as well read it before the release ships, when its findings can still change the patch.

The strongest objection is one Stenberg raises himself: public handling will give bad people "a slightly longer window of opportunity." He's right, and he limits it. Only bugs below HIGH go public, and HIGH and CRITICAL stay private. The private route wasn't free either. His maintainers are "strained, overloaded and brought to the brink," and a private queue nobody can clear isn't secrecy. It's a backlog, and the HIGH report waits in it behind nine lesser ones.

Side by side, the three show where the disclosure question has moved. It used to be how long a fix could stay secret. Now it is how fast the people running the code can install it, and maintainers control only half of that clock. For PHP, the project has done what a source project can: picked the minute, told everyone, kept the right to go early. What happens in the fifteen minutes after 14:00 UTC depends on whether your update path is a cron job or a calendar invite.