3 ms·

How would you do it then? Publish as soon as it's discovered, and let everyone scramble for fixes as its being exploited?

caio1982 9y ago
0. fucking put the pressure on Intel and other chip makers to have microcode updates ready by NYE, like, you know, 6 months after the first report 1. make sure all tier 1 companies involved are equally patched and on the same page as far as mitigations go before EOY, then involve tier 2 companies (see news on "the impromptu war room") a full month before the embargo deadline 2. not commit or patch anything or fly commented diffs around in the freaking public LKML; git branches to be tested and secondary mailing lists can be private if only for a brief period of time That's definitely not what happened, and probably the dirty details have not surfaced yet. I can't wait for this to be reasonably over so we can start to read post mortem on the whole process.
- euyyn 9y ago
  You can't really force a different company to have patches and updates by a certain deadline, can you. The only hard leverage is the officially planned disclosure date.
nbsd4lyfe 9y ago
Notify groups who have to develop fixes (in this case: OS, compiler developers). Especially when they have a record of not violating embargoes and good faith in fixing issues. When the longer time for fixes is done, post an announcement in private pre-disclosure lists. For a very complicated change, give a few days of private testing and provide patches and details to groups that must apply the patches (oss-sec distro list, etc.) For a simple one with existing backports, notify that <DATE> is publication date for a type of vulnerability to <PROGRAM>. Wait 2-4 weeks to publish a working exploit. Don't notify bodies who don't have their own custom code that must be fixed, but happen to pay you enough money. The latter is actually what happened in this case and it's immensely frustrating.

caio1982 9y ago

0. fucking put the pressure on Intel and other chip makers to have microcode updates ready by NYE, like, you know, 6 months after the first report 1. make sure all tier 1 companies involved are equally patched and on the same page as far as mitigations go before EOY, then involve tier 2 companies (see news on "the impromptu war room") a full month before the embargo deadline 2. not commit or patch anything or fly commented diffs around in the freaking public LKML; git branches to be tested and secondary mailing lists can be private if only for a brief period of time That's definitely not what happened, and probably the dirty details have not surfaced yet. I can't wait for this to be reasonably over so we can start to read post mortem on the whole process.

euyyn 9y ago
You can't really force a different company to have patches and updates by a certain deadline, can you. The only hard leverage is the officially planned disclosure date.

nbsd4lyfe 9y ago

Notify groups who have to develop fixes (in this case: OS, compiler developers). Especially when they have a record of not violating embargoes and good faith in fixing issues. When the longer time for fixes is done, post an announcement in private pre-disclosure lists. For a very complicated change, give a few days of private testing and provide patches and details to groups that must apply the patches (oss-sec distro list, etc.) For a simple one with existing backports, notify that <DATE> is publication date for a type of vulnerability to <PROGRAM>. Wait 2-4 weeks to publish a working exploit. Don't notify bodies who don't have their own custom code that must be fixed, but happen to pay you enough money. The latter is actually what happened in this case and it's immensely frustrating.