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