{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-12\n📝 Original message:On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote:\n\u003e I think it's relevant to treat different bug severity levels with different\n\u003e response plans. \n\nThat makes sense.\n\nFor comparison, Monero defines a response process that has three levels\nand varies the response for each:\n\n]     a. HIGH: impacts network as a whole, has potential to break entire\n]        network, results in the loss of monero, or is on a scale of great\n]        catastrophe\n]     b. MEDIUM: impacts individual nodes, wallets, or must be carefully\n]        exploited\n]     c. LOW: is not easily exploitable\n\n -- https://github.com/monero-project/monero/blob/master/VULNERABILITY_RESPONSE_PROCESS.md\n\nAmong other things, HIGH gets treated as an emergency, MEDIUM get fixed\nin a point release; LOW get deferred to the next regular release eg.\n\nAdditionally, independently of the severity, Monero's doc says they'll\neither get their act together with a fix and report within 90 days,\nor otherwise the researcher that found the vulnerability has the right\nto publically disclose the issue themselves...\n\nI wouldn't say that's a perfect fit for bitcoin core (at a minimum, given\nthe size of the ecosystem and how much care needs to go into releases,\nI think 90 days is probably too short), but it seems better than current\npractice...\n\nFor comparison, if you're an altcoin developer or just bitcoin core user,\nand are trying to work out whether the software you're using is secure;\nif you do a quick google and end up at:\n\n  https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures\n\nyou might conclude that as long as you're running version 0.11 or later,\nyou're fine. That doesn't seem like an accurate conclusion for people\nto draw; but if you're not tracking every commit/PR, how do you do any\nbetter than that?\n\nMaybe transitioning from keeping things private indefinitely to having\na public disclosure policy is tricky. Maybe it might work to build up to it,\nsomething like:\n\n  * We'll start releasing info about security vulnerabilities fixed in\n    0.12.0 and earlier releases as of 2018-01-01\n  * Then we'll continue with 0.13.0 and earlier as of 2018-03-01\n  * Likewise for 0.14.0 as of 2018-05-01\n  * Thereafter we'll adopt a regular policy at http://...\n\nThat or something like it at least gives people relying on older,\npotentially vulnerable versions a realistic chance to privately prepare\nand deploy any upgrades or fixes they've missed out on until now.\n\nCheers,\naj"}