Two disclosures today, and only one of them could afford to wait
Serguey Asael Shinder3 min readTwo security disclosures crossed the desk within hours of each other today, and they took opposite approaches to the oldest question in the field: when do you tell people?
F5 published an advisory for a heap overflow in BIG-IP APM scoring 9.8, with hotfixes named for all three affected release trains and an iRule workaround available through support. Textbook sequence: fix first, then tell.
Radicle published two critical flaws in its wire protocol — no confidentiality, and peer authentication that can be spoofed — and said so explicitly:
"We are publishing this before the security update is available."
Conventional wisdom says Radicle got it wrong. It did not, and the reason is worth separating from the personalities involved.
The test is where the harm sits in time
The argument for coordinated disclosure is that a public advisory arms attackers during the window before defenders can patch. That argument has a hidden premise: the patch is the defence. It usually is. An unpatched BIG-IP is exploitable today and not exploitable after the hotfix, so every day of silence before the hotfix exists is a day of reduced risk, and every day after is a day of increased risk. The calculus is clean.
Radicle's flaws break that premise. The exposure is confidentiality of data already sent. Someone sitting on the network path between two nodes has been able to read what passed and to pull private repositories on demand, and that happened — or did not — before any of us heard about it. A backward-incompatible release next month changes nothing about last month's traffic.
So the two questions come apart. Does disclosure increase future harm? Yes, slightly, as always. Does silence reduce past harm? No. It cannot. And once that second answer is no, the operator who might rotate a key, stop syncing a private repository or move a node behind a tunnel is the only person the information can still help — and withholding it helps only the project.
Which is why the comment under the LWN piece lands
The first reader response points out that the project is said to have known for three months and shipped four releases in that time without a word. If that is right, then the sentence "you can act on it today" was true in June as well, and the reasoning that makes today's publication correct is also the reasoning that makes the three months of silence hard to defend. The principle does not only justify the disclosure; it indicts the delay.
There is a version of this that is not a criticism of Radicle specifically. Every project that discovers a design-level flaw — not a bug, a property of the protocol — faces a fix that is a breaking change, and a breaking change takes months. The honest move is to separate the two clocks: tell people the day you know, ship the break when it is ready. What is hard to justify is treating the second clock as permission to pause the first.
The practical residue
For anyone triaging both stories this week, the difference is entirely operational.
The F5 flaw has a closed question attached to it: which of your virtual servers carry an access policy and an OAuth profile at the same time? Answer it, patch those, done.
The Radicle flaws have an open one: what has already been read? That question has no patch, and it is the kind that decides whether a disclosure was useful or merely correct.