{"type":"rich","version":"1.0","author_name":"npub195kxyxuphpjdahqnptumzvk8vdvvvx23dpatke97pc5854tsuymql99yu2","author_url":"https://nostr.ae/npub195kxyxuphpjdahqnptumzvk8vdvvvx23dpatke97pc5854tsuymql99yu2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-11\n📝 Original message:I think it's relevant to treat different bug severity levels with different\nresponse plans.\n\nE.g.\nCompromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)\nCompromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley\nDB -\u003e LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of\ncoins)\nCompromising Node performance (Various node-specific DoS attacks)\n\nShould have different disclosure policies, IMO\n\nOn Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I don't think I know the right answer here, but I will point out two\n\u003e things that make this a little more complicated.\n\u003e\n\u003e 1 - There are lots of altcoin developers and while I'm sure the majority\n\u003e would greatly appreciate the disclosure and would behave responsibly with\n\u003e the information, I don't know where you draw the line on who you tell and\n\u003e who you don't.\n\u003e\n\u003e 2- Unlike other software, I'm not sure good security for bitcoin is\n\u003e defined by constant upgrading.  Obviously upgrading has an important\n\u003e benefit, but one of the security considerations for Bitcoin is knowing that\n\u003e your definition of the money hasn't changed.  Much harder to know that if\n\u003e you change software.\n\u003e\n\u003e\n\u003e\n\u003e On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e I believe there continues to be concern over a number of altcoins which\n\u003e\u003e \u003e are running old, unpatched forks of Bitcoin Core, making it rather\n\u003e\u003e \u003e difficult to disclose issues without putting people at risk (see, eg,\n\u003e\u003e \u003e some of the dos issues which are preventing release of the alert key).\n\u003e\u003e \u003e I'd encourage the list to have a discussion about what reasonable\n\u003e\u003e \u003e approaches could be taken there.\n\u003e\u003e\n\u003e\u003e That seems like it just says bitcoin core has two classes of users:\n\u003e\u003e people who use it directly following mainnet or testnet, and people who\n\u003e\u003e make derived works based on it to run altcoins.\n\u003e\u003e\n\u003e\u003e Having a \"responsible disclosure\" timeline something like:\n\u003e\u003e\n\u003e\u003e  * day -N: vulnerability reported privately\n\u003e\u003e  * day -N+1: details shared amongst private trusted bitcoin core group\n\u003e\u003e  * day 0: patch/workaround/mitigation determined, CVE reserved\n\u003e\u003e  * day 1: basic information shared with small group of trusted users\n\u003e\u003e       (eg, altcoin maintainers, exchanges, maybe wallet devs)\n\u003e\u003e  * day ~7: patches can be included in git repo\n\u003e\u003e       (without references to vulnerability)\n\u003e\u003e  * day 90: release candidate with fix available\n\u003e\u003e  * day 120: official release including fix\n\u003e\u003e  * day 134: CVE published with details and acknowledgements\n\u003e\u003e\n\u003e\u003e could make sense. 90 days / 3 months is hopefully a fair strict upper\n\u003e\u003e bound for how long it should take to get a fix into a rc; but that's still\n\u003e\u003e a lot longer than many responsible disclosure timeframes, like CERT's at\n\u003e\u003e 45 days, but also shorter than some bitcoin core minor update cycles...\n\u003e\u003e Obviously, those timelines could be varied down if something is more\n\u003e\u003e urgent (or just easy).\n\u003e\u003e\n\u003e\u003e As it is, not publishing vulnerability info just seems like it gives\n\u003e\u003e everyone a false sense of security, and encourages ignoring good security\n\u003e\u003e practices, either not upgrading bitcoind nodes, or not ensuring altcoin\n\u003e\u003e implementations keep up to date...\n\u003e\u003e\n\u003e\u003e I suppose both \"trusted bitcoin core group\" and \"small group of trusted\n\u003e\u003e users\" isn't 100% cypherpunk, but it sure seems better than not both not\n\u003e\u003e disclosing vulnerability details, and not disclosing vulnerabilities\n\u003e\u003e at all... (And maybe it could be made more cypherpunk by, say, having\n\u003e\u003e the disclosures to trusted groups have the description/patches get\n\u003e\u003e automatically fuzzed to perhaps allow identification of leakers?)\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e aj\n\u003e\u003e\n\u003e\u003e \u003e On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:\n\u003e\u003e \u003e \u003e Hi,\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Given today's presentation by Chris Jeffrey at the Breaking Bitcoin\n\u003e\u003e \u003e \u003e conference, and the subsequent discussion around responsible\n\u003e\u003e disclosure\n\u003e\u003e \u003e \u003e and industry practice, perhaps now would be a good time to discuss\n\u003e\u003e \u003e \u003e \"Bitcoin and CVEs\" which has gone unanswered for 6 months.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017\n\u003e\u003e -March/013751.html\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e To quote:\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e \"Are there are any vulnerabilities in Bitcoin which have been fixed\n\u003e\u003e but\n\u003e\u003e \u003e \u003e not yet publicly disclosed?  Is the following list of Bitcoin CVEs\n\u003e\u003e \u003e \u003e up-to-date?\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e There have been no new CVEs posted for almost three years, except for\n\u003e\u003e \u003e \u003e CVE-2015-3641, but there appears to be no information publicly\n\u003e\u003e available\n\u003e\u003e \u003e \u003e for that issue:\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e It would be of great benefit to end users if the community of clients\n\u003e\u003e \u003e \u003e and altcoins derived from Bitcoin Core could be patched for any known\n\u003e\u003e \u003e \u003e vulnerabilities.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Does anyone keep track of security related bugs and patches, where the\n\u003e\u003e \u003e \u003e defect severity is similar to those found on the CVE list above?  If\n\u003e\u003e \u003e \u003e yes, can that list be shared with other developers?\"\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Best Regards,\n\u003e\u003e \u003e \u003e Simon\n\u003e\u003e \u003e \u003e _______________________________________________\n\u003e\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/06bf75a1/attachment.html\u003e"}