19:00:43 #startmeeting 19:00:43 Meeting started Thu Mar 9 19:00:43 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:47 hi 19:01:02 short topic: great work on 0.14 all! 19:01:07 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt 19:01:08 instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs 19:01:20 yes! congrats all on another great release 19:01:37 +1 19:02:08 * BlueMatt has seen really great results for miners that have upgraded to 0.14 =D 19:02:08 yes i feel like we did a good job getting most of the major things we wanted into it! 19:02:16 net seems to have really helped a lot 19:02:50 hi 19:03:02 proposed topic: disclosure of alert key (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1534 reminded me) 19:03:16 Hi. 19:03:49 There are DOS vulnerablities in older verions that the final alert does not block. :( 19:03:55 #topic alert key disclosure timeline 19:04:05 gmaxwell: below what version? 19:04:12 (unfortunately the old code is stupid) 19:04:18 what kind of DOS vulns? 19:04:21 All versions. They're worse in older ones. 19:04:38 (obviously all versions with alerts enabled) 19:04:51 when was that changed? 19:04:53 yes, what kind? just a slowdown, or a crash, or potential remote code execution? 19:05:00 OOM 19:05:04 No RCE, just OOM. 19:05:41 so versions <0.12.0 affected? 19:05:52 well. some versions have already been marked as "insecure" on bitcoin.org due to other bugs. Let me see what the threshold is. 19:06:09 when was the alert feature disabled by default? 19:06:16 0.12.1 19:06:29 oh 19:06:39 wumpus: we have a list somewhere? 19:06:46 are there any major altcoins forked before 0.12 that did not change the alaert key? 19:07:00 https://bitcoin.org/bin/insecure/ 19:07:01 All the 0.14 nodes sending final alerts constantly is somewhat protective, but unforuntately not absoltely protective. 19:07:22 sipa: already looked for that, there were no major ones, but some obscure & dead ones that have been nagged. 19:07:40 There are also funds paid to the alert key in the network, I believe 0.01 BTC or so. :P 19:08:18 heheh 19:08:25 heh 19:08:27 in any case, one possibility would be to not worry too much about it, announce again that version <0.12.1 are vulnerable (there is a lot else they're vulnerable too, I think). 19:08:29 surprised no one ever swiped that 19:08:46 sipa: most altcoins are on <0.12 codebase, and many never changed the alter key 19:08:53 btcdrak: not so. 19:09:08 from what I've seen, altcoins generally do change the alert key, at least from the bitcoin one 19:09:15 btcdrak: (didn't change the _litecoin_ alert key, yes, but I searched extensively for this already, months ago.) 19:09:17 many have the litecoin or feathercoin key 19:09:20 yes :) 19:09:43 ah 19:09:47 ah yes, most coins forked from litecoin (and didnt change the network magic either) 19:09:59 remind me again what the advantage is of disclosing the key? 19:10:23 morcos: making the alert system entirely unreliable (as if it weren't already) 19:10:25 to not be responsible for someone else abusing it, among other things. 19:10:41 we don't believe the key is actually secure right now in any case. 19:10:54 there is no hurry in disclosing it either 19:11:11 just a nice to have to close that chapter 19:11:18 to force people to not use it anymore 19:11:24 they key is useless now anyway that final alert is out. 19:11:25 and also for sake of history 19:11:26 We can make people upgrade because of the planned alert key discolsure... 19:11:37 not sure how litecoin alerts are affects if they use a different key 19:11:42 we can't make anyone upgrade, and even if we could we wouldn't. :) 19:11:43 yes but if there is even nuisance harm that can be done with it.. i think we should announce that its not considred secure but that we're not going to aid people doing nuisance with it by publicly disclosing it until a) we see nuisance or b) some predetermine future point 19:11:52 litecoin is not affected luke-jr - what they do is up to them 19:12:13 wumpus: they also removed the alert system, but there's a lot on 0.10.x nodes in litecoin 19:12:24 morcos: well we're at the predetermined future point now, we announced.. 6 months ago we'd do this after 0.14. The issue there is on careful review of the old code I found several DOS vulnerablities. 19:12:37 yes, this was announced on a timeline 19:12:56 right, so change the predetermined point to be further out... the risk is only that someone blames us for nuisance right? 19:13:02 maybe just push back the date even further until <0.12.1 nodes are even fewer? 19:13:25 yea, I would vote push another release given old 0.12.0 isnt otherwise insecure? 19:13:32 right, if anyone abuses the key now, they may blame us. If it is public knowledge not so much. 19:13:35 It's fine with me, we should emphasize that those older versions are insecure. If someone dosses them later it's not the end of the world. 19:13:52 Except of course we will be blamed if we make it public and someone creates nuisance with it! 19:14:02 BlueMatt: I believe it is otherwise insecure at a greater magnitude than the alert DOS attacks. 19:14:06 gmaxwell, yes, and by emphasizing it, maybe people update... 19:14:26 Well anything that has alerts is displaying the hardcoded final alert now... 19:14:33 what version did BU remove the alert system? If it is in their 0.12.1, people could dos them, and I don't think they would take kindly to that (drama and FUD and all that) 19:14:42 so let's announce the vulnerability first that should motivate more people to upgrade old systems or disable the alert system. 19:14:43 which says something like (allcaps) warning alert key compromised! upgrade required!. 19:14:53 ACK " there is no hurry in disclosing it either" 19:15:34 gmaxwell: can you get a CVE assigned for one or more of the old DoS? 19:15:38 I think some of you are underestimating the cost of this thing... but sure, no rush required. 19:15:44 anyhow, everyone with the alert key could disclose it, even anonymously 19:16:12 don't even know who has it exactly so... 19:16:14 yes, nobody can be blamed individually if nobody knows who disclosed it 19:16:39 anyhow, any other topics? 19:17:27 FWIW, ignoring alert keys, I see 539 vulnerable nodes (0.94%) 19:17:28 Can we get a clear plan of action here? We'll CVE old versions and remind people these old things are insecure? should we review other fixes and determine if we want to set a higher bar for holy-shit-dont-run-that than 0.12.1? 19:18:02 updating http://luke.dashjr.org/programs/bitcoin/files/charts/security.html to consider <0.12.1 vulnerable, that goes to 2606 vulnerable nodes (4.54%) 19:18:37 you can't be entirely sure that all of them are vulnerable, they may have patched the code to remove the alert system 19:18:48 sure, but that's unlikely 19:18:53 I think 5% dropping offline would be inconsequential, so avoiding the dos is just a politeness to the users to avoid disrupting other things they may have going on. 19:19:02 many are running old versions to be able to run their own (outdated) patches on top 19:19:25 gmaxwell: how about CVE the dos vulns you found, post messages an all forums about vulnerable nodes, and then release the key a few weeks later? 19:19:32 if we're really worried, we could release a 0.12.2 with just those exploits fixed 19:19:41 or maybe simply disabling alerts 19:19:49 luke-jr: 0.12.1 has them disabled. 19:19:52 luke-jr: 0.12.1 already disabled alrets 19:19:54 if it was me, i wouldn't do any of it... lets put our effort where it matters.. 0.15 19:19:55 oh, duh 19:20:09 so why wouldn't people held back by patches just rebase? 19:20:13 to 0.12.1 19:20:24 0.12.0 can easily upgrad to 0.12.1, 0.11.x maybe less so 19:20:47 considering there's an alert message broadcasting to all those vulnerable nodes right now saying they should upgrade, I think we've probably done enough. 19:20:55 not going to do a new 0.11.x release though 19:21:55 get and publish a CVE, then 2 weeks later publish the key 19:21:57 ? 19:22:23 I guess we could push a patch to the 0.11 branch that disables the alert system 19:22:33 it's a trivial patch. 19:22:40 yes 19:22:42 luke-jr: +1 19:23:08 nothing before 0.8 still works at all, and the 0.9x nodes I have looked at are all fake. 19:23:21 0.10 / 0.11 are probably still running in practice. 19:23:56 luke-jr: okay fine with CVE and we can patch the old branch. thats enough plan for me for now. 19:24:11 it's a one-line patch, could even do a tag, just not going to build executables for them anymore 19:25:55 Thanks. 19:26:44 sgtm 19:27:10 I suppose the bitcoin.org alert page should be updated with that info then 19:27:11 I'm happy to review any backports for an alert patch, even if they're old, won't go below 0.8, sorry 19:28:29 everything from 0.10 and below is EOL https://bitcoincore.org/en/lifecycle/#schedule 19:29:06 btcdrak: 0.14 should be added to that page 19:29:29 sipa: https://github.com/bitcoin-core/bitcoincore.org/pull/347 19:29:45 what other subjects? 19:30:54 Is there a timeline for 0.14.1? Or just when deemed necessary? 19:31:07 it seems that 0.10 is the only one that needs an alert disabling patch. 0.11 already has it, just not tagged 19:31:22 cfields: eh not really; any pressing reason you'd want one right away? 19:32:05 the more-than-8-addnode hang at shutdown problem is annoying but not enough to warrant an immediate release 19:32:10 I don't see a reason one couldn't wait a few weeks, though we do have material for one. 19:32:17 wumpus: nope, just couldn't remember if we usually set a date or just wing it 19:32:29 no, we never set dates in advance for minor releases 19:32:46 for 0.15 I've posted the release schedule: https://github.com/bitcoin/bitcoin/issues/9961 19:33:09 I'm sure that some more things will show up for 0.14.1 in not too long as people start using some of the new features. 19:33:35 yes 19:33:36 I feel like those should have been caught during RCs.. 19:33:47 'should have been' 19:33:54 #9959 and #9955 are interesting for 0.14.1 19:33:56 https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub 19:33:57 https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 19:34:33 there's always issues in major releases that only get found when the final is tagged, it's a fact of life 19:34:42 achow101: any kind of bug that requires special configuration to find is much less likely to get caught, this is why you hear groans when people propose solving problems with more config options. :) 19:34:46 no number of rcs can solve that 19:34:46 9955 is more of a new feature IMO, but I don't care if people want to backport it 19:34:58 agreed, we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release 19:35:08 ok tagging them 19:36:13 wumpus: 0.15 schedule sgtm. 19:36:36 note that backporting 9955 is likely a hazard since priority mining doesn't pay attention to fIncludeWitness I think 19:36:38 cfields: thanks, good to know 19:37:03 should be a trivial thing to fix, but might not conflict 19:37:43 are we going to do the release notes wiki thing again? 19:38:03 yes, at the end of the 0.15 release cycle 19:38:22 ok 19:38:42 priority mining did pay attention to fIncludeWitness, so i think it would be fine, but i haven't tested 19:39:33 achow101: I think it worked quite well; the only problem that came up is merging it with that is in the tree. So better to leave it until the end when people start caring about writing release notes, and until then leave it up to pulls to add something there 19:39:47 oh, it's tested in a different place, okay 19:41:48 anything else? 19:43:25 seems not 19:44:31 I don't think so 19:44:45 #endmeeting