2 ms·
we can just nuke the caches for all the domains that turned on the problematic features (Scrape Shield, etc.) No, IIUC it's MUCH worse than that : a single ngi
by renaudg 10y ago
we can just nuke the caches for all the domains that turned on the problematic features (Scrape Shield, etc.)
No, IIUC it's MUCH worse than that : a single nginx process would serve many different domains, and you would only need one of them with the problematic features turned on to trigger the bug, and potentially leak data from all other domains served by that same process (whether those other domains had the feature enabled or not)
I'm not familiar enough with CF's infrastructure to make an educated guess about the way they shard domains across their nginx fleet (assuming this is what they do), but in order to be able to produce a list of all "tainted" domains that were being served together on the same nginx process, at any point in time since September 2016, well their nginx config generation process had better be perfectly deterministic (and any changes thoroughly logged over time). Also, the bigger the shards, the more neighboring domains are affected by a single "poisoned" one, and the more widespread the problem is.
My guess is that if they had had a way to reliably piece together that information, they would have released a list by now.
- bigiain 10y ago> My guess is that if they had had a way to reliably piece together that information, they would have released a list by now. Or they've got that list - and it's so vast and scary that legal and/or the board refuse to even acknowledge its existence…