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