{"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-10\n📝 Original message:On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev wrote:\n\u003e I believe there continues to be concern over a number of altcoins which\n\u003e are running old, unpatched forks of Bitcoin Core, making it rather\n\u003e difficult to disclose issues without putting people at risk (see, eg,\n\u003e some of the dos issues which are preventing release of the alert key).\n\u003e I'd encourage the list to have a discussion about what reasonable\n\u003e approaches could be taken there.\n\nThat seems like it just says bitcoin core has two classes of users:\npeople who use it directly following mainnet or testnet, and people who\nmake derived works based on it to run altcoins.\n\nHaving a \"responsible disclosure\" timeline something like:\n\n * day -N: vulnerability reported privately\n * day -N+1: details shared amongst private trusted bitcoin core group\n * day 0: patch/workaround/mitigation determined, CVE reserved\n * day 1: basic information shared with small group of trusted users\n      (eg, altcoin maintainers, exchanges, maybe wallet devs)\n * day ~7: patches can be included in git repo\n      (without references to vulnerability)\n * day 90: release candidate with fix available\n * day 120: official release including fix\n * day 134: CVE published with details and acknowledgements\n\ncould make sense. 90 days / 3 months is hopefully a fair strict upper\nbound for how long it should take to get a fix into a rc; but that's still\na lot longer than many responsible disclosure timeframes, like CERT's at\n45 days, but also shorter than some bitcoin core minor update cycles...\nObviously, those timelines could be varied down if something is more\nurgent (or just easy).\n\nAs it is, not publishing vulnerability info just seems like it gives\neveryone a false sense of security, and encourages ignoring good security\npractices, either not upgrading bitcoind nodes, or not ensuring altcoin\nimplementations keep up to date...\n\nI suppose both \"trusted bitcoin core group\" and \"small group of trusted\nusers\" isn't 100% cypherpunk, but it sure seems better than not both not\ndisclosing vulnerability details, and not disclosing vulnerabilities\nat all... (And maybe it could be made more cypherpunk by, say, having\nthe disclosures to trusted groups have the description/patches get\nautomatically fuzzed to perhaps allow identification of leakers?)\n\nCheers,\naj\n\n\u003e On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:\n\u003e \u003e Hi,\n\u003e \u003e \n\u003e \u003e Given today's presentation by Chris Jeffrey at the Breaking Bitcoin\n\u003e \u003e conference, and the subsequent discussion around responsible disclosure\n\u003e \u003e and industry practice, perhaps now would be a good time to discuss\n\u003e \u003e \"Bitcoin and CVEs\" which has gone unanswered for 6 months.\n\u003e \u003e \n\u003e \u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.html\n\u003e \u003e \n\u003e \u003e To quote:\n\u003e \u003e \n\u003e \u003e \"Are there are any vulnerabilities in Bitcoin which have been fixed but\n\u003e \u003e not yet publicly disclosed?  Is the following list of Bitcoin CVEs\n\u003e \u003e up-to-date?\n\u003e \u003e \n\u003e \u003e https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures\n\u003e \u003e \n\u003e \u003e There have been no new CVEs posted for almost three years, except for\n\u003e \u003e CVE-2015-3641, but there appears to be no information publicly available\n\u003e \u003e for that issue:\n\u003e \u003e \n\u003e \u003e https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641\n\u003e \u003e \n\u003e \u003e It would be of great benefit to end users if the community of clients\n\u003e \u003e and altcoins derived from Bitcoin Core could be patched for any known\n\u003e \u003e vulnerabilities.\n\u003e \u003e \n\u003e \u003e Does anyone keep track of security related bugs and patches, where the\n\u003e \u003e defect severity is similar to those found on the CVE list above?  If\n\u003e \u003e yes, can that list be shared with other developers?\"\n\u003e \u003e \n\u003e \u003e Best Regards,\n\u003e \u003e Simon\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 bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}