1 2014-04-09 00:00:36 <aschildbach_> Hmm at least 0.9.0 is vulnerable?
  2 2014-04-09 00:00:47 <aschildbach_> And users should upgrade, no?
  3 2014-04-09 00:01:44 <theymos> Did anyone figure out how much data can be stolen when Bitcoin acts as a TLS client?
  4 2014-04-09 00:02:25 <gmaxwell> aschildbach_: There are two areas that we use SSL in Bitcoin core.  One is RPC ssl which is off by default and a PITA to turn on, not widely used, and also blocked from public access by default.  When acting as an RPC server, I tested extensively, and we leak only the prior rpc request and then 64k of zero bytes.
  5 2014-04-09 00:02:55 <gmaxwell> As an RPC client I don't have any way to test, though the exposure there could be at most leaking your client cert if you connected to a malicious server.
  6 2014-04-09 00:03:09 <Mqrius> Any word on when the launchpad bitcoin ppa is gonna update to 0.9.1? It's still at 0.9.0
  7 2014-04-09 00:03:25 <aschildbach_> I'm more concerned about the PP
  8 2014-04-09 00:03:52 <aschildbach_> Because all you need is click the "wrong" link.
  9 2014-04-09 00:03:53 <gmaxwell> The other is the payment protocol, and like the rpc client I don't currently have a way to test. In general, both due to heap layout and the fact that the secure allocator zeroize lower my concern somewhat. But until I get an exploit working as a server I'm unsure.
 10 2014-04-09 00:04:28 <theymos> It may be best to issue an alert for 0.9.0 just in case.
 11 2014-04-09 00:04:45 <gmaxwell> Perhaps. It's certantly good to upgrade just in case.
 12 2014-04-09 00:04:52 <Mqrius> Does armory use an rpc link with bitcoind?
 13 2014-04-09 00:05:04 <Mqrius> (rpcssl, specifically)
 14 2014-04-09 00:05:05 <aschildbach_> The transaction malleability also has no exploit possibility and it still got an alert.
 15 2014-04-09 00:05:24 <gmaxwell> No it didn't.
 16 2014-04-09 00:05:30 <aschildbach_> (Actually it not even got a release)
 17 2014-04-09 00:05:34 <aschildbach_> It did.
 18 2014-04-09 00:05:40 <aschildbach_> https://bitcoin.org/en/alert/2014-02-11-malleability
 19 2014-04-09 00:05:52 <dexX7> it appears the complete ssl traffic can be sniffed. this is not a bitcoin issue, but "huge"
 20 2014-04-09 00:06:15 <sipa> aschildbach_: was that an alert?
 21 2014-04-09 00:06:26 <gmaxwell> There was no alert sent on the network. It looks like someone made a page on bitcoin.org to answer questions.
 22 2014-04-09 00:06:27 <aschildbach_> Well the page says "alert".
 23 2014-04-09 00:06:47 <sipa> aschildbach_: i can't recall, and i can't see why - there was no need to ask people to upgrade as nobody but themselves were ever affected
 24 2014-04-09 00:06:48 <aschildbach_> I'm not talking about the P2P alert system.
 25 2014-04-09 00:06:52 <sipa> oh ok
 26 2014-04-09 00:07:00 <aschildbach_> I'm talking about the web page.
 27 2014-04-09 00:07:00 <warren> Mqrius: if the PPA is built against the system openssl then the package doesn't need a rebuild
 28 2014-04-09 00:07:05 <sipa> right, ok
 29 2014-04-09 00:07:15 <gmaxwell> what a confusing thing.
 30 2014-04-09 00:07:23 <Mqrius> warren: I have no idea if it is.
 31 2014-04-09 00:07:29 <sipa> well, some page like that certainly seems appropriate
 32 2014-04-09 00:07:43 <sipa> but a p2p doesn't, for thr same reason
 33 2014-04-09 00:08:11 <gmaxwell> sure, though I don't think we actually know the degree of impact at this time, so that makes it a bit harder.  For some reason I can't get the SSL server handshake to work right. :-/
 34 2014-04-09 00:09:17 <sipa> just an update "in which way does the heartbleed openssl bug affect bitcoin", and list cases in which you're certainly not affected etc
 35 2014-04-09 00:09:43 <sipa> i'm sure many people are worried
 36 2014-04-09 00:10:23 <gmaxwell> yea, I've seen a lot of bad information going around, like people telling people they need to move their funds to new addresses and other stuff that probably isn't needed and will not help for subtle reasons.
 37 2014-04-09 00:11:38 <Luke-Jr> gmaxwell: you've confirmed that no Qt/SSL release will leak ECDSA priv keys when fetching a payment request?
 38 2014-04-09 00:12:23 <gmaxwell> Luke-Jr: No, I don't have a way to confirm that yet. I've only been able to test the RPC.  I believe it's _unlikely_ but I'm not sure all of what QT is doing.
 39 2014-04-09 00:12:52 <Luke-Jr> gmaxwell: when in doubt, my advice is to be safe :P
 40 2014-04-09 00:13:07 <gmaxwell> Otherwise I wouldn't also suggest people upgrade. I think upgrading is prudent. I misunderstood aschildbach_ as saying we should send a network alert.
 41 2014-04-09 00:13:18 <gmaxwell> and I'm less convinced that would be a good idea.
 42 2014-04-09 00:13:51 <Luke-Jr> if there's a *chance* of ECDSA key leakage, I think it's prudent to warn people not to use PP in 0.9.0 and if they have make a new wallet..
 43 2014-04-09 00:13:53 <theymos> Why? The alert won't be so burdensome if targeted only to 0.9.0.
 44 2014-04-09 00:14:55 <gmaxwell> theymos: it's not only applicable to 0.9.0 though, it's applicable to things linked with that version of the openssl... oh hm. because the payment protocol.
 45 2014-04-09 00:15:18 <warren> Mqrius: find the bitcoin-qt binary, run ldd, pastebin the output
 46 2014-04-09 00:16:06 <theymos> The RPC stuff is pretty minor, but if 0.9.0 can be attacked via PP, then that's extremely severe. Even if it's unlikely, I think that an alert is prudent.
 47 2014-04-09 00:16:35 <gmaxwell> theymos: OK.  We don't know if it can be attacked via the PP, it's a possibility.
 48 2014-04-09 00:17:24 <Luke-Jr> gmaxwell: if there's a chance of a major problem like that, people should be alerted. they can always ignore it or upgrade to 0.9.1..
 49 2014-04-09 00:17:32 <wildpaavo> where do i report a massive bitcoin vulnerability?
 50 2014-04-09 00:17:49 <Luke-Jr> gmaxwell: it's impossible to rule out the chance, either, given the wide variety of Qt versions that could be in use
 51 2014-04-09 00:18:07 <Luke-Jr> wildpaavo: bitcoin-security@lists.sourceforge.net
 52 2014-04-09 00:18:22 <Mqrius> With the attack, can it read arbitrary memory, or only memory related to the SSL session? If the former, can't it have any data, such as ecdsa keys, if they were in memory at the time?
 53 2014-04-09 00:18:47 <Luke-Jr> Mqrius: memory from the same process, but not of the attacker's choice (I think)
 54 2014-04-09 00:18:55 <gmaxwell> Mqrius: it can read the first 64kbytes on the heap _after_ the openssl allocation for the heartbeat data.
 55 2014-04-09 00:19:12 <gmaxwell> not data before or further away or... etc.
 56 2014-04-09 00:19:15 <Luke-Jr> gmaxwell: the Heartbleed thing said > 64 kB was possible?
 57 2014-04-09 00:19:32 <Luke-Jr> "There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed."
 58 2014-04-09 00:19:47 <gmaxwell> Thats misleading.
 59 2014-04-09 00:20:04 <Luke-Jr> I guess it's always 64 kB after the allocation, and the allocation may be different each time?
 60 2014-04-09 00:20:19 <gmaxwell> It reads 64k after the allocation, you can try again and maybe the allocation shows up someplace else and lets you read something else, but it's always the 64k after the allocation.
 61 2014-04-09 00:20:23 <gmaxwell> Right.
 62 2014-04-09 00:20:50 <gmaxwell> (which was why when I tested the rpc I started up 5 attacks concurrently while calling a bunch of rpcs to make sure I always got the same result)
 63 2014-04-09 00:20:57 <Luke-Jr> anyhow, I still think it's impossible to rule out a major problem with PP
 64 2014-04-09 00:21:07 <gmaxwell> this isn't to say something weird might happen in some other case, so it's good to upgrade but my confidence is fairly high on the rpc.
 65 2014-04-09 00:21:24 <Luke-Jr> gmaxwell: for RPC, did you try different compilers and optimisation flags? :P
 66 2014-04-09 00:21:47 <Luke-Jr> although heap probably wouldn't change much
 67 2014-04-09 00:22:02 <Luke-Jr> since that's libc more than the compiler probably
 68 2014-04-09 00:22:03 <aschildbach_> fyi. I just updated Bitcoin Wallet so it doesn't do any HTTP(S) on Android 4.1.1. -- until we get a better fix. Want to stay on the safe side.
 69 2014-04-09 00:22:07 <gmaxwell> Luke-Jr: nont our problem.
 70 2014-04-09 00:22:37 <gmaxwell> Luke-Jr: I mean we only ship openssl in our own binaries, otherwise it depends on the system.
 71 2014-04-09 00:22:38 <Luke-Jr> aschildbach_: kinda makes PP useless? :x
 72 2014-04-09 00:22:53 <aschildbach_> Luke-Jr: furtunately we still have the fallback
 73 2014-04-09 00:23:00 <Luke-Jr> gmaxwell: fair enough
 74 2014-04-09 00:23:42 <aschildbach_> Luke-Jr: and probably will have that for several decades. HTTP/TCP is not reliable anyway.
 75 2014-04-09 00:23:58 <gmaxwell> FWIW, I tested the 0.9.1 binary and confirm it doesn't respond to the misformed heartbeat messages.
 76 2014-04-09 00:24:45 <gmaxwell> If I thought the payment protocol was not going to allow for the reliable collection of refund addresses I would have opposed its inclusion in Bitcoin Core.  I think thats really unfortunate.
 77 2014-04-09 00:25:09 <gmaxwell> aschildbach_: don't you still make https connections out to get the payment requests?
 78 2014-04-09 00:25:23 <aschildbach_> gmaxwell: no
 79 2014-04-09 00:25:36 <aschildbach_> (only on Android 4.1.1, of course)
 80 2014-04-09 00:26:31 <gmaxwell> aschildbach_: how do you get the payment request in the first place then?
 81 2014-04-09 00:27:24 <aschildbach_> gmaxwell: How do you mean? BIP21 PR I get via URL
 82 2014-04-09 00:27:38 <aschildbach_> gmaxwell: QR or NFC or Link.
 83 2014-04-09 00:27:53 <gmaxwell> aschildbach_: right so how is getting it via URL not resulting in making a connection?
 84 2014-04-09 00:28:22 <Mqrius> Practically, do I need to change my passwords and 2-factor keys everywhere? Or just delete my cookies?
 85 2014-04-09 00:29:46 <xtheloniousx> Hey, I'm trying to cross compile bitcoin on linux using mingw
 86 2014-04-09 00:30:17 <xtheloniousx> I wasn't able to find a single solid guide that works
 87 2014-04-09 00:30:30 <xtheloniousx> I'm running into issues cross compiling berkeley db
 88 2014-04-09 00:30:40 <aschildbach_> gmaxwell: It just doesn't do the connection.
 89 2014-04-09 00:31:36 <gmaxwell> xtheloniousx: if you want to cross compile you should setup to gitian build. Those instructions work. :)
 90 2014-04-09 00:31:48 <xtheloniousx> oh ok
 91 2014-04-09 00:31:53 <aschildbach_> gmaxwell: Its like if the r= parameter wasn't present.
 92 2014-04-09 00:32:26 <xtheloniousx> thanks :) Yeah I've been spending the last couple of hours hacking libraries that I'm sure work out the box
 93 2014-04-09 00:32:27 <gmaxwell> oh I see, so payment protocol is not working over the web at all on android wallet right now with your changes. Gotcha.
 94 2014-04-09 00:33:16 <aschildbach_> gmaxwell: ?
 95 2014-04-09 00:33:39 <aschildbach_> gmaxwell: at all? Again, its only 4.1.1
 96 2014-04-09 00:33:59 <gmaxwell> Okay, I missed that constraint. Gotcha.
 97 2014-04-09 00:34:01 <aschildbach_> gmaxwell: Also, the payment protocol has this fallback via BIP72 to BIP21.
 98 2014-04-09 00:34:11 <aschildbach_> gmaxwell: And BIP21 works as expected.
 99 2014-04-09 00:37:48 <aschildbach_> FWIW: I just calculated the change will affect 4.03% of the active users.
100 2014-04-09 00:39:24 <gmaxwell> ::nods:: I misunderstood initially. I thought you were saying that it still recieved the payment request but then didn't send a response, and I missed— initially— that it was limited to android 4.1.1.
101 2014-04-09 00:46:30 <midnightmagic> huh. that's interesting. my gitian build doesn't match. must've done something wrong..
102 2014-04-09 00:47:14 <aschildbach_> midnightmagic: did you re-build the dependencies?
103 2014-04-09 00:47:28 <midnightmagic> aschildbach_: I'm about to rebuild everything from scratch now.
104 2014-04-09 00:48:04 <aschildbach_> midnightmagic: openssl obviously has changed and the -qt dependency too (probably transitively)
105 2014-04-09 00:48:23 <aschildbach_> good nite everyone!
106 2014-04-09 00:48:27 <midnightmagic> night
107 2014-04-09 00:48:32 <fanquake> morning
108 2014-04-09 00:53:40 <Mqrius> warren: pastebin.com/VxiEb20a it says openssl version 1.0.0. Also, my system says I'm running 1.0.1e, but it can't find any updates. I don't think I have it open to the outside world though, I'd think armory just needs localhost.
109 2014-04-09 00:54:55 <gmaxwell> Mqrius: you have to work to turn on rpc to the outside world, and you have to work more to enable rpcssl.
110 2014-04-09 00:55:32 <gmaxwell> to exposure yourself on the rpc side you need to add rpcallowip=* and rpcssl=1 and you have to generate a ssl certificate.
111 2014-04-09 00:56:14 <Mqrius> I didn't do anything for that, so it should still be default then. Alright, I guess armory is safe. The next step is to change my passwords on all the exchanges I suppose.
112 2014-04-09 00:57:54 <Mqrius> ...and 2-factor keys? Or will they never be in the heap?
113 2014-04-09 01:03:22 <gmaxwell> Mqrius: I'm not sure if its in the release version yet, but I know the latest armory stuff constantly phones home (and to AWS) to check for updates. So that could be exposed if your SSL is unpached.
114 2014-04-09 01:04:55 <Mqrius> gmaxwell: Alright. Any idea why it doesn't update openssl when I apt-get upgrade and apt-get update? Is the new version not in the stable branch yet?
115 2014-04-09 01:05:03 <Mqrius> (ubuntu 13.10)
116 2014-04-09 01:05:29 <warren> did they patch an old version, and you're expecting 1.0.1g?
117 2014-04-09 01:05:35 <warren> Fedora/RHEL have 1.0.1e patched
118 2014-04-09 01:05:54 <Mqrius> Oh, could be.
119 2014-04-09 01:06:00 <warren> are there logs of when updates happened?
120 2014-04-09 01:06:35 <Mqrius> Yeah, lemme check
121 2014-04-09 01:11:12 <Mqrius> It updated 8 April, 4:49 am. www.pastebin.com/gDeNK9CR
122 2014-04-09 01:11:25 <Mqrius> Seems fine then, I guess. (@ warren )
123 2014-04-09 01:15:07 <Mqrius> "openssl version -a" also shows that it was built on the 7th of April, which is correct according to the Internet.
124 2014-04-09 01:18:27 <vetch> gmaxwell: Armory connects to a bunch of websites to see if its connection is alive and doesn't work if you block the requests. it's sort of icky really.
125 2014-04-09 01:18:54 <vetch> gmaxwell: might be false reverse DNS lookups for aws, come to think of it. I'll have to check.
126 2014-04-09 01:24:09 <phantomcircuit> Mqrius, the patched version is still 1.0.1e
127 2014-04-09 01:24:29 <phantomcircuit> the latest verion in ubuntu is 1.0.1e-3ubuntu1.2
128 2014-04-09 01:24:31 <phantomcircuit> version*
129 2014-04-09 01:26:16 <Mqrius> phantomcircuit: Yeah, looks like I'm good then :) thanks
130 2014-04-09 01:51:55 <warren> wumpus: http://miniupnp.free.fr/files/changelog.php?file=miniupnpc-1.9.20140401.tar.gz
131 2014-04-09 01:52:04 <warren> 2013/10/07:
132 2014-04-09 01:52:04 <warren>   fixed potential buffer overrun in miniwget.c
133 2014-04-09 01:52:04 <warren>   Modified UPNP_GetValidIGD() to check for ExternalIpAddress
134 2014-04-09 02:09:50 <gmaxwell> so, I'm looking at the miniupnpc 1.6 source.
135 2014-04-09 02:11:22 <gmaxwell> and It looks like the only consequence of it is a read-past-the-end-of-a-stack-allocated-buffer. A second opinion would be nice.
136 2014-04-09 02:11:59 <coryfields> gmaxwell: 1.6 is what we ship?
137 2014-04-09 02:12:11 <warren> we ship 1.8
138 2014-04-09 02:12:19 <gmaxwell> I think so? I'm not sure. (thats partly why I mentioned it).  Ah. someone should update our docs.
139 2014-04-09 02:12:25 <coryfields> ok
140 2014-04-09 02:12:28 <warren> URL?
141 2014-04-09 02:12:34 <coryfields> yea, i was just poking through the 1.8 i had laying around
142 2014-04-09 02:12:41 <coryfields> guess that's why it's laying around...
143 2014-04-09 02:13:14 <warren> None of the distros appear to be shipping 1.9 yet.
144 2014-04-09 02:13:25 <coryfields> gmaxwell: where were you looking? 1.8 code doesn't have UPNP_GetValidIGD in miniwget.c
145 2014-04-09 02:13:52 <gmaxwell> UPNP_GetValidIGD is just how miniwget gets called
146 2014-04-09 02:14:53 <gmaxwell> the bug is the while loop around line 160 of miniwget.c
147 2014-04-09 02:14:54 <coryfields> ok, assumed as much, just didn't want to chase ghosts if i was on the other end of a code shuffle
148 2014-04-09 02:15:26 <gmaxwell> s/stack/heap/
149 2014-04-09 02:15:33 <gmaxwell> while(header_buf[i]=='\r' || header_buf[i] == '\n')i++; < bug
150 2014-04-09 02:16:34 <warren> https://github.com/miniupnp/miniupnp/commit/3a87aa2f10bd7f1408e1849bdb59c41dd63a9fe9
151 2014-04-09 02:17:03 <gmaxwell> oh good, you found the actual commit. :P
152 2014-04-09 02:18:30 <todam00n> is the order of txins inside a transaction ever important?
153 2014-04-09 02:18:47 <todam00n> for signing for example
154 2014-04-09 02:22:05 <coryfields> gmaxwell: at first glance, i agree
155 2014-04-09 02:22:23 <coryfields> i don't see any glaring side-effects outside that loop
156 2014-04-09 02:25:37 <coryfields> hmm, getting i to overflow to -max_int could get interesting though
157 2014-04-09 02:34:30 <warren> gmaxwell: what document says 1.6?
158 2014-04-09 02:36:51 <kankles> whats going on on testnet?
159 2014-04-09 02:36:59 <kankles> the blocks are being mined like every second
160 2014-04-09 02:51:52 <warren> coryfields: https://github.com/bitcoin/bitcoin/pull/4025
161 2014-04-09 02:52:43 <coryfields> warren: i saw. will chime in tomorrow. locked out of github atm.
162 2014-04-09 02:54:35 <phantomcircuit> warren, i fail to see how any of those changes improve the existing code
163 2014-04-09 02:54:56 <warren> phantomcircuit: I didn't imply it did, just was making sure cory was aware of it
164 2014-04-09 02:59:38 <coryfields> heh
165 2014-04-09 02:59:52 <coryfields> phantomcircuit == patrick?
166 2014-04-09 03:00:00 <phantomcircuit> yes
167 2014-04-09 03:00:18 <phantomcircuit> if anything we should be going backwards so that debian stable works again...
168 2014-04-09 03:00:25 <phantomcircuit> but that makes building windows binaries annoying
169 2014-04-09 03:00:28 <coryfields> dammit, now i might have to go dig out that phone so i can login and fight :p
170 2014-04-09 03:01:21 <phantomcircuit> coryfields, for or against?
171 2014-04-09 03:01:25 <warren> phantomcircuit: https://github.com/theuni/bitcoin/commits/libc-compat
172 2014-04-09 03:02:03 <coryfields> phantomcircuit: depends. I'm building with 4.8 now and checking the libc symbols... so i don't look like an ass if you're right :)
173 2014-04-09 03:02:56 <warren> phantomcircuit: people here felt it was important enough to have the same VM's for gitian linux and windows builds that it broke glibc < 2.15 compat in 0.9.0.  0.9.1 ships static linked glibc/libstdc++ which works on those older distros.  This allows a dynamic linked glibc to work.
174 2014-04-09 03:03:14 <phantomcircuit> warren, ah
175 2014-04-09 03:03:31 <warren> the benefit of dynamic linked glibc is ASLR works
176 2014-04-09 03:03:41 <warren> previous gitian linux builds didn't have it
177 2014-04-09 03:04:27 <coryfields> phantomcircuit: I ask that if you're going to throw around "no sane distros" etc, you at least have a metric for determining what's too new vs. what support is missing
178 2014-04-09 03:13:17 <coryfields> phantomcircuit: gcc 4.8 didn't produce any new glibc dependencies...
179 2014-04-09 03:13:21 <coryfields> no surprise there, though
180 2014-04-09 03:13:45 <coryfields> bumping the build distro is what causes those problems
181 2014-04-09 03:14:02 <phantomcircuit> coryfields, tbh the problem i think is more likely is someone using something that only works in gcc 4.8
182 2014-04-09 03:14:32 <coryfields> phantomcircuit: sure. if you want to argue feature support, that's valid
183 2014-04-09 03:14:36 <coryfields> just pick an argument :p
184 2014-04-09 03:16:47 <coryfields> from what i've seen while diving pretty deep into c++11 (it's hard to go back after), gcc 4.8/clang 3.4 have built everything i've thrown at em
185 2014-04-09 03:17:15 <coryfields> enough to call it "good enough" imo. iirc gcc is still missing a few minor features
186 2014-04-09 03:18:20 <coryfields> so that'd be my personal line in the sand. If the argument is that 4.8/3.4 aren't ubiquitous enough, that'd be a good discussion to have
187 2014-04-09 03:18:24 <phantomcircuit> coryfields, gcc 4.8 is not even available in debian stable
188 2014-04-09 03:18:37 <phantomcircuit> 4.7 isn't even the default
189 2014-04-09 03:18:50 <Luke-Jr> coryfields: 4.8 isn't even considered stable on Gentoo
190 2014-04-09 03:19:40 <kdomanski> hey, are you talking about that C++11 thing?
191 2014-04-09 03:20:20 <coryfields> if those things are true, then i'd concede
192 2014-04-09 03:21:06 <Luke-Jr> coryfields: IMO we should support at least the latest stable version of any major distro
193 2014-04-09 03:21:20 <Luke-Jr> which means RHEL 6 is going to be holding us back for a while..
194 2014-04-09 03:21:58 <kdomanski> doesn't RHEL 6 have berkeley db < 4.8 ?
195 2014-04-09 03:22:32 <coryfields> Luke-Jr: well user distros really don't matter in this case, just what devs build on...
196 2014-04-09 03:22:45 <coryfields> Luke-Jr: but debian+gentoo are certainly major data points there
197 2014-04-09 03:23:04 <Luke-Jr> coryfields: they do matter.
198 2014-04-09 03:23:09 <coryfields> also, i'll admit to a heavy bias. I'm a big fan of c++11.
199 2014-04-09 03:23:24 <Luke-Jr> I don't blame anyone for wanting C++11 ;p
200 2014-04-09 03:23:46 <coryfields> Luke-Jr: I already conceded, you don't have to keep going :)
201 2014-04-09 03:24:03 <Luke-Jr> kdomanski: you're right!
202 2014-04-09 03:24:19 <Luke-Jr> 
ACTION wonders if that's an excuse to not support RHEL 6 (in addition to lack of ECDSA)

203 2014-04-09 03:24:22 <kdomanski> I understand Luke-Jr is against C++11 ?
204 2014-04-09 03:24:24 <coryfields> 
ACTION un-concedes.

205 2014-04-09 03:24:26 <Luke-Jr> kdomanski: …
206 2014-04-09 03:24:41 <kdomanski> coryfields: Debian and Gentoo both have GCC 4.7, which compiles the C++11 changes just fine
207 2014-04-09 03:25:00 <coryfields> kdomanski: gcc can't build c++11 for crap
208 2014-04-09 03:25:05 <Luke-Jr> warren: ping, any opinions?
209 2014-04-09 03:25:38 <warren> Luke-Jr: the gitian binaries need to support the long-term stable distros
210 2014-04-09 03:25:41 <kdomanski> you know what they say, "it works on my end"
211 2014-04-09 03:25:50 <coryfields> kdomanski: iirc delegating a constructor is enough to get it to ICE
212 2014-04-09 03:26:05 <warren> Luke-Jr: a newer compiler can be installed on any distro, the output can be filtered for glibc symbols
213 2014-04-09 03:26:06 <kdomanski> I see
214 2014-04-09 03:26:21 <kdomanski> btw new Ubuntu LTS is out this month
215 2014-04-09 03:26:23 <Luke-Jr> warren: so it's okay if we drop compile-on-RHEL6 support? :p
216 2014-04-09 03:26:39 <Luke-Jr> kdomanski: really?
217 2014-04-09 03:26:39 <warren> well, it already doesn't compile due to openssl
218 2014-04-09 03:27:08 <warren> what exactly does dropping compile-on-older-distros again us?
219 2014-04-09 03:27:16 <kdomanski> Luke-Jr: are you being sarcastic?
220 2014-04-09 03:27:19 <Luke-Jr> "latest stable" != "older"
221 2014-04-09 03:27:24 <Luke-Jr> kdomanski: no
222 2014-04-09 03:27:56 <Luke-Jr> oh, 14.04 isn't released yet :o
223 2014-04-09 03:28:33 <Luke-Jr> nevermind
224 2014-04-09 03:28:36 <kdomanski> but soon, these patches aren't going to get released with new Bitcoin Core before then
225 2014-04-09 03:29:16 <warren> gain us*
226 2014-04-09 03:30:59 <coryfields> kdomanski: http://pastebin.com/raw.php?i=2v25V4V4
227 2014-04-09 03:31:05 <coryfields> ^^ enough to break 4.7
228 2014-04-09 03:31:20 <kdomanski> I see
229 2014-04-09 03:31:25 <coryfields> trying now, it fails to compile. In my real code at the time, it ICE'd
230 2014-04-09 03:32:05 <kdomanski> long term OpenSuse has 4.8
231 2014-04-09 03:34:14 <Luke-Jr> seems GCC 4.7 is sufficient for everything on the current C++11 PR except std::unique_ptr
232 2014-04-09 03:34:18 <Luke-Jr> which is libstdc++
233 2014-04-09 03:34:25 <Luke-Jr> having trouble finding a version requirement on that
234 2014-04-09 03:34:30 <coryfields> Luke-Jr: would you agree that it's reasonable to set some criteria, then? eg. when debian/gentoo stable support a build-dep, it's clear to use
235 2014-04-09 03:35:00 <coryfields> i'm not sure that RHEL as a marker is conducive
236 2014-04-09 03:35:09 <Luke-Jr> coryfields: seems reasonable to me
237 2014-04-09 03:35:38 <Luke-Jr> when RHEL adds ECDSA support, it should be added to the requirement list
238 2014-04-09 03:36:15 <coryfields> makes sense imo to come up with some rough policy like ^^, rather than throwing darts every time something is suggested
239 2014-04-09 03:37:43 <warren> set a sunset date for RHEL6
240 2014-04-09 03:38:16 <coryfields> how many devs build on RHEL?
241 2014-04-09 03:39:08 <coryfields> or put another way... name a dev who builds on RHEL :p
242 2014-04-09 03:39:16 <Luke-Jr> gmaxwell might
243 2014-04-09 03:39:27 <warren> I run it on RHEL6 but don't build it there.
244 2014-04-09 03:39:48 <coryfields> warren: right, that's my point. build-deps and user-deps are separate discussions.
245 2014-04-09 03:40:14 <coryfields> Luke-Jr: i'm conveniently ignoring yours :)
246 2014-04-09 03:40:25 <Luke-Jr> coryfields: ?
247 2014-04-09 03:40:57 <coryfields> your point
248 2014-04-09 03:40:57 <warren> RHEL7 might be an excellent replacement for gitian VM, 10 years of support on a distro with gcc-4.8.2
249 2014-04-09 03:41:52 <kdomanski> but it will never have C++17
250 2014-04-09 03:41:58 <kdomanski> :P
251 2014-04-09 03:41:59 <coryfields> 14 :)
252 2014-04-09 03:42:38 <Luke-Jr> sometimes I wish C had templates.
253 2014-04-09 03:42:40 <kdomanski> yeah, but 14 has marginal feature changes, while 17 incorporates a third of BOOST into an ISO standard
254 2014-04-09 03:43:03 <coryfields> kdomanski: 14 makes constexpr what it should've been... that's a biggie for me
255 2014-04-09 03:43:07 <Luke-Jr> kdomanski: just a third? :<
256 2014-04-09 03:43:50 <kdomanski> Luke-Jr: let me find you some detailed data...
257 2014-04-09 03:44:01 <justanotheruser> As someone who isn't a c++ master, why do people hate on boost so much?
258 2014-04-09 03:44:09 <coryfields> iirc for 14 they punted on sockets again?
259 2014-04-09 03:44:39 <warren> coryfields: why did you include -rdynamic ?
260 2014-04-09 03:44:53 <Luke-Jr> coryfields: C++14 isn't final yet, go join them and demand resolution! :P
261 2014-04-09 03:44:56 <kdomanski> nobody hates boost, dropping a library dependency is always good
262 2014-04-09 03:45:31 <coryfields> kdomanski: i hate boost with a burning passion...
263 2014-04-09 03:45:47 <Luke-Jr> we could conceivably replace boost with Qt
264 2014-04-09 03:45:53 <coryfields> warren: heavy hammer for symbol exporting
265 2014-04-09 03:46:08 <warren> coryfields: to aid in debugging?
266 2014-04-09 03:46:12 <kdomanski> deploying it on some obscure arch is a pain in the ass, I'd prefer simply having a port of modern compiler/stdlib
267 2014-04-09 03:46:46 <coryfields> kdomanski: sure, i hate it only because of deploying it. even on the most standard hardware
268 2014-04-09 03:46:51 <coryfields> well, that and the docs suck
269 2014-04-09 03:46:53 <kdomanski> Luke-Jr: Qt is an abomination to build
270 2014-04-09 03:46:57 <warren> coryfields: (what purpose)?
271 2014-04-09 03:47:06 <Luke-Jr> kdomanski: better than boost :P
272 2014-04-09 03:47:15 <coryfields> warren: no, it's necessary for runtime
273 2014-04-09 03:47:26 <coryfields> Luke-Jr: i'd call them about equally evil
274 2014-04-09 03:47:43 <kdomanski> I've used BOOST on ARM CPU within a robot, don't even get me started with Qt
275 2014-04-09 03:47:43 <Luke-Jr> oh well, that's why I use Gentoo. don't have to worry about the details. :P
276 2014-04-09 03:48:07 <Luke-Jr> I've used Bitcoin Core GUI on ARM CPU within a handheld computer <.<
277 2014-04-09 03:48:21 <Luke-Jr> Gentoo on Nokia N900 ftw
278 2014-04-09 03:48:25 <kdomanski> Luke-Jr: yeah, I always return to Gentoo when I need some serious development to be done
279 2014-04-09 03:48:35 <coryfields> kdomanski: i built osx x86 qt on linux x64. I can relate :)
280 2014-04-09 03:48:39 <coryfields> it's a nightmare.
281 2014-04-09 03:49:01 <Luke-Jr> I should make sure Bitcoin Core builds on x32..
282 2014-04-09 03:49:04 <coryfields> Luke-Jr: running on arm android here :)
283 2014-04-09 03:49:14 <Luke-Jr> coryfields: ew
284 2014-04-09 03:49:47 <coryfields> this seems to be the saddest e-penis contest ever...
285 2014-04-09 03:49:51 <kdomanski> sometimes I need to use a SPARC core without an MMU - I can use parts of BOOST there, but Qt?
286 2014-04-09 03:49:52 <Luke-Jr> lol
287 2014-04-09 03:50:01 <Luke-Jr> kdomanski: ………………………….
288 2014-04-09 03:50:09 <kdomanski> huh
289 2014-04-09 03:50:18 <kdomanski> I thought we were just bashing Qt
290 2014-04-09 03:50:38 <coryfields> kdomanski: well, if you want a third to bash.. throw python in there
291 2014-04-09 03:50:49 <kdomanski> sonofa...
292 2014-04-09 03:50:55 <coryfields> those are the top 3 on my hate list
293 2014-04-09 03:50:57 <justanotheruser> Kdoma
294 2014-04-09 03:51:00 <Luke-Jr> let's add Python to Bitcoin Core to allow users to script their own policy!
295 2014-04-09 03:51:03 <Luke-Jr> 
ACTION hides

296 2014-04-09 03:51:25 <coryfields> Luke-Jr: only if it's python 3.4...
297 2014-04-09 03:51:35 <Luke-Jr> coryfields: doesn't meet distro dep requirements
298 2014-04-09 03:51:41 <Luke-Jr> gotta use 3.3? :P
299 2014-04-09 03:51:49 <Luke-Jr> 
ACTION starts x32 build of BCCore

300 2014-04-09 03:51:57 <coryfields> heh
301 2014-04-09 03:52:09 <Luke-Jr> >>> Failed to emerge dev-util/boost-build-1.52.0-r1, Log file:
302 2014-04-09 03:52:11 <Luke-Jr> >>>  '/var/tmp/portage/dev-util/boost-build-1.52.0-r1/temp/build.log'
303 2014-04-09 03:52:12 <Luke-Jr> ()%*#) boost
304 2014-04-09 03:52:17 <kdomanski> I liked it better when we were masturbating to modern C++
305 2014-04-09 03:52:19 <Luke-Jr> ^ see, we should switch to Qt
306 2014-04-09 03:52:20 <coryfields> ok, enough ot for me
307 2014-04-09 03:52:24 <kdomanski> so to speak
308 2014-04-09 03:53:23 <coryfields> warren: something is loaded at runtime, i didn't investigate what yet. that's enough for a POC
309 2014-04-09 03:53:46 <coryfields> warren: i've been testing my code against a bitcoind built that way all night, no issues to speak of
310 2014-04-09 03:55:18 <warren> Luke-Jr: wouldn't 32bit address space fail soon?
311 2014-04-09 03:55:21 <gjs278> can QT be used to build an app like bitcoind
312 2014-04-09 03:55:27 <gjs278> or does it have to be gui
313 2014-04-09 03:57:13 <coryfields> warren: have you tested those changes?
314 2014-04-09 03:57:44 <kdomanski> Luke-Jr: http://isocpp.org/std/status
315 2014-04-09 03:58:02 <kdomanski> just remember
316 2014-04-09 03:58:03 <kdomanski> any URL may lead directly or indirectly to COIN-STEALING MALWARE
317 2014-04-09 03:58:05 <Luke-Jr> warren: no?
318 2014-04-09 03:58:23 <Luke-Jr> gjs278: Qt support console apps
319 2014-04-09 04:00:09 <coryfields> supports WinCE too. Equally good candidates :)
320 2014-04-09 04:00:33 <kdomanski> Qt is so hip and cool it has it's own QString class, because std::string is so mainstream
321 2014-04-09 04:00:34 <Luke-Jr> warren: from 2003-2011 I used x86_64, but I finally went back to x86_32 in 2012. so x32 is a welcome improvement.
322 2014-04-09 04:00:54 <Luke-Jr> kdomanski: Qt is to C++ what C++ is to C ☺
323 2014-04-09 04:01:11 <coryfields> he says with a unicode smiley...
324 2014-04-09 04:01:12 <Luke-Jr> "C++ is so hip and cool it has it's own std::string class, because char* is so mainstream"
325 2014-04-09 04:01:40 <Luke-Jr> see, it works!
326 2014-04-09 04:02:03 <kdomanski> Qt is to C++ what Silverlight is to Flash
327 2014-04-09 04:02:26 <Luke-Jr> I'd never use Silverlight or Flash, so I can't relate.
328 2014-04-09 04:02:55 <Luke-Jr> coryfields: autotools fails ☹
329 2014-04-09 04:03:05 <coryfields> Luke-Jr: nah, i just have \u263A\n memorized
330 2014-04-09 04:03:06 <Luke-Jr> checking whether the Boost::System library is available... yes
331 2014-04-09 04:03:07 <Luke-Jr> configure: error: Could not find a version of the library!
332 2014-04-09 04:03:31 <coryfields> Luke-Jr: context?
333 2014-04-09 04:03:36 <kdomanski> me neither, but's it's just one of those cases, where you reinvent something in order to improve nothing significant and add some overhead
334 2014-04-09 04:03:36 <Luke-Jr> # ls /usr/libx32/libboost_system*
335 2014-04-09 04:03:38 <Luke-Jr> /usr/libx32/libboost_system-mt.so  /usr/libx32/libboost_system.so  /usr/libx32/libboost_system.so.1.52.0
336 2014-04-09 04:03:45 <Luke-Jr> coryfields: building bitcoin-qt
337 2014-04-09 04:04:03 <coryfields> Luke-Jr: cripes... wtf kind of prefix is that...
338 2014-04-09 04:04:12 <Luke-Jr> coryfields: standard for x32
339 2014-04-09 04:04:27 <warren> coryfields: 32bit address space with x86_64 GPR's
340 2014-04-09 04:04:53 <coryfields> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/4019
341 2014-04-09 04:05:16 <Luke-Jr> coryfields: I don't see how that would help
342 2014-04-09 04:05:26 <warren> Luke-Jr: oh... was that concern limited to leveldb mmap
343 2014-04-09 04:05:27 <coryfields> Luke-Jr: fix should be pretty clear from that, patch would be appreciated
344 2014-04-09 04:05:33 <coryfields> Luke-Jr: ?
345 2014-04-09 04:05:46 <Luke-Jr> warren: no, orphan block storage IBD issues
346 2014-04-09 04:05:49 <warren> coryfields: sorry, still trying to put out a different fire
347 2014-04-09 04:06:10 <Luke-Jr> coryfields: wow, that logic is so broken
348 2014-04-09 04:06:11 <warren> trying it now
349 2014-04-09 04:06:30 <coryfields> Luke-Jr: those macros are a trainwreck...
350 2014-04-09 04:06:30 <Luke-Jr> coryfields: uname -m tells you nothing about the OS architecture, just the kernel..
351 2014-04-09 04:07:04 <coryfields> Luke-Jr: but ultimately it's boost's fault for not shipping something to help find what it installs, so i gave up on proper fixes
352 2014-04-09 04:07:08 <Luke-Jr> I'm surprised it builds on my real system O.o
353 2014-04-09 04:07:45 <coryfields> Luke-Jr: yea. They even have perfectly good build/host/target vars to use and for some reason they don't
354 2014-04-09 04:08:19 <Luke-Jr> something tells me if I install x86_64 boost, I won't be able to build anymore :x
355 2014-04-09 04:08:45 <coryfields> Luke-Jr: if i were you, i'd add your (weird) string there, push it upstream, and call it a day
356 2014-04-09 04:08:58 <coryfields> the urge to fix what's broken there only leads to pain and suffering
357 2014-04-09 04:09:14 <Luke-Jr> :<
358 2014-04-09 04:09:29 <coryfields> unless you want to take on all of boost's modules, that is :)
359 2014-04-09 04:09:46 <Luke-Jr> .. I'd sooner make a serious push to port to Qt only
360 2014-04-09 04:10:15 <coryfields> Luke-Jr: ^^ is why i'm so pro-c++11. It lets us cut lots of boost
361 2014-04-09 04:10:29 <coryfields> but sadly, most of what gets cut is header-only anyway
362 2014-04-09 04:11:18 <Luke-Jr> 0.8.6 builds fine on x32
363 2014-04-09 04:11:26 <Luke-Jr> 
ACTION makes it coryfields's bug? :P

364 2014-04-09 04:11:51 <coryfields> heh, sure, but you have to verify my two-line fix
365 2014-04-09 04:13:15 <Luke-Jr> ok..
366 2014-04-09 04:13:22 <Luke-Jr> this going to fix both issues? ;)
367 2014-04-09 04:13:49 <coryfields> both?
368 2014-04-09 04:14:03 <Luke-Jr> 1) libx32
369 2014-04-09 04:14:16 <coryfields> the first being your clownshoes prefix? :p
370 2014-04-09 04:14:16 <Luke-Jr> 2) using the actual OS arch, even if kernel-arch libs are available
371 2014-04-09 04:14:39 <kdomanski> coryfields: actually, I'm about to cut boost_chrono
372 2014-04-09 04:14:58 <kdomanski> which is of course impossible without C++11
373 2014-04-09 04:14:59 <coryfields> kdomanski: ah yep, good example
374 2014-04-09 04:15:12 <coryfields> and that ships a lib, right?
375 2014-04-09 04:15:20 <Luke-Jr> coryfields: if I have x86_64 boost installed, bccore 0.9 tries to use it
376 2014-04-09 04:15:21 <kdomanski> yup
377 2014-04-09 04:15:27 <Luke-Jr> even though my OS is x86_32
378 2014-04-09 04:15:45 <Luke-Jr> I think
379 2014-04-09 04:16:07 <kdomanski> if the thread interruption mechanism could be somehow changed a bit, we could cut entire boost_thread too
380 2014-04-09 04:16:09 <coryfields> Luke-Jr: what's your host string according to configure?
381 2014-04-09 04:16:13 <kdomanski> and that's a big one
382 2014-04-09 04:16:33 <Luke-Jr> coryfields:
383 2014-04-09 04:16:34 <Luke-Jr> configure:2651: checking host system type
384 2014-04-09 04:16:36 <Luke-Jr> configure:2664: result: x86_64-unknown-linux-gnu
385 2014-04-09 04:16:52 <kdomanski> then it's just boost::filesystem::file_copy I think - no more libs
386 2014-04-09 04:17:14 <kdomanski> IIRC
387 2014-04-09 04:18:29 <coryfields> kdomanski: the one that really gets on my nerves is io_service
388 2014-04-09 04:18:44 <kdomanski> ah. right...
389 2014-04-09 04:18:56 <kdomanski> I'll take a closer look later this week
390 2014-04-09 04:19:06 <coryfields> it's shipped as a lib because of some dependency on some boost exception class
391 2014-04-09 04:19:20 <coryfields> which is standard c++11 now
392 2014-04-09 04:19:21 <kdomanski> oh god
393 2014-04-09 04:19:33 <coryfields> Luke-Jr: that's not what we're after
394 2014-04-09 04:19:36 <coryfields> Luke-Jr: sec for something to grep
395 2014-04-09 04:20:31 <coryfields> Luke-Jr: hmm, maybe it is...
396 2014-04-09 04:20:54 <coryfields> Luke-Jr: clearly i don't understand how x32 works.
397 2014-04-09 04:22:13 <Luke-Jr> coryfields: the 2nd issue exists on my current x86_32 system, not just x32
398 2014-04-09 04:22:24 <Luke-Jr> I think. Based just on reading the code.
399 2014-04-09 04:22:28 <Luke-Jr> still trying to confirm
400 2014-04-09 04:22:46 <Luke-Jr> crossdev is being broken today
401 2014-04-09 04:22:52 <coryfields> Luke-Jr: the PR linked above was pulled in today
402 2014-04-09 04:24:47 <coryfields> time for bed. Luke-Jr feel free to yell on the commits if they've broken something. i'll take a look tomorrow
403 2014-04-09 04:26:07 <warren> grrr
404 2014-04-09 04:26:20 <warren> gitian only works with signed, not annotated tags?
405 2014-04-09 04:27:26 <coryfields> works fine with any commit-ish for me
406 2014-04-09 04:27:27 <Luke-Jr> warren: you can't sign unannotated tags..
407 2014-04-09 04:29:12 <warren> git tag -a is unsigned tags
408 2014-04-09 04:38:45 <warren> devrandom: does gitian have a way to specify the number of -j's you want from the outside?
409 2014-04-09 04:39:25 <coryfields> gbuild -j
410 2014-04-09 04:40:35 <warren> coryfields:
411 2014-04-09 04:40:39 <warren> coryfields: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(codecvt.o): relocation R_X86_64_32S against `vtable for std::codecvt<char, char, __mbstate_t>' can
412 2014-04-09 04:40:39 <warren> not be used when making a shared object; recompile with -fPIC
413 2014-04-09 04:40:39 <warren> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value
414 2014-04-09 04:40:53 <warren> coryfields: i386 build succeeded, failed during x86-64 here
415 2014-04-09 04:43:36 <coryfields> warren: link some results on those commits and i'll take a look tomorow. brain's checked out for the night.
416 2014-04-09 04:43:49 <warren> ok
417 2014-04-09 04:46:17 <coryfields> warren: if you feel like messing with it anymore in the meantime, see wumpus's pie changes for full static
418 2014-04-09 04:46:57 <coryfields> nnite
419 2014-04-09 04:47:36 <warren> yeah, already trying it
420 2014-04-09 04:47:54 <gjs278> Luke-Jr: do you use pypy as your main python yet
421 2014-04-09 04:48:43 <gjs278> I'd love an x32 system, I just finished up making everything that can be pypy work except for emerge --sync. I'm still using emerge-webrsync
422 2014-04-09 04:50:15 <Luke-Jr> gjs278: pypy only supports ancient Python 2 afaik
423 2014-04-09 04:50:22 <Luke-Jr> I only use Python 3
424 2014-04-09 04:50:31 <gjs278> gotcha
425 2014-04-09 04:52:10 <warren> -  # Disable hardening in configure and manually pass 'static-safe' hardening flags
426 2014-04-09 04:52:10 <warren> # For 64-bit, -pie with -static causes a link error
427 2014-04-09 04:52:22 <warren> coryfields: I'm afraid we will need to filter the libstdc++ symbols
428 2014-04-09 05:01:47 <warren> wumpus: hmm, I didn't realize that you had to completely disable hardening for that static x86_64 build.  yikes.
429 2014-04-09 05:34:59 <warren> which Debian release has glibc-2.11?
430 2014-04-09 05:38:58 <warren> there's duplicate gitian instructions in gitian-descriptors/README.md and release-process.md
431 2014-04-09 05:39:03 <warren> they tend to fall out of sync
432 2014-04-09 06:23:36 <msvb-lab> Any docs with guidance on using gitian to produce deterministic builds?
433 2014-04-09 06:23:52 <msvb-lab> Or the history of the gitian build system (which I believe was developed by Bitcoin folks?)
434 2014-04-09 06:24:39 <fanquake> https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
435 2014-04-09 06:24:49 <fanquake> https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md
436 2014-04-09 06:25:05 <fanquake> https://github.com/devrandom/gitian-builder
437 2014-04-09 06:27:35 <gmaxwell> coryfields: right, my thought on the overflow is that you're going to either crash or hit a CR/LF before you read 2 gigabytes with very high probablity. I'm glad you had the same read on it I did.
438 2014-04-09 06:28:57 <gmaxwell> Luke-Jr: wrt GCC, generally GCC's reliablity has increased a lot in recent versions. I have a general preference to moving to 4.8 as soon as we reasonably can.
439 2014-04-09 06:29:17 <gmaxwell> (a bunch of code gen bugs have been fixed— some even found by me)
440 2014-04-09 06:30:56 <jrmithdobbs> i'd say i wonder if there's any actual noticable performance with clang vs gcc but lol c++ =/
441 2014-04-09 06:31:27 <scumb4g> http://trilema.com/2014/the-sins-of-the-group-of-posers-behind-the-so-called-bitcoin-foundation/?utm_source=twitterfeed&utm_medium=twitter
442 2014-04-09 06:31:58 <msvb-lab> fanquake: Thanks, very friendly to do my searching for me.
443 2014-04-09 06:32:00 <msvb-lab> Should have guessed that the canonical home of gitian was on github.
444 2014-04-09 06:32:22 <msvb-lab> Actually using it for tor though, so I wasn't sure if the name is the same everywhere it's applied.
445 2014-04-09 06:33:00 <fanquake> msvb-lab Just happened I had them open in a couple tabs, otherwise you'd be duckduckgo bound :P
446 2014-04-09 06:35:02 <msvb-lab> fanquake: Yep, understood. Ddg.gg. Gitian is quite nice, just wrote a page on it at: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/BuildingWithGitian/
447 2014-04-09 06:35:19 <msvb-lab> ...which is probably full of fake science and other errors. I wrote pretty fast.
448 2014-04-09 06:37:07 <msvb-lab> Going to link now to https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
449 2014-04-09 06:37:26 <msvb-lab> ...which resembles very much my VM setup doc https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/VMSetup/
450 2014-04-09 06:37:46 <warren> wumpus: sorry, read it more carefully now
451 2014-04-09 06:37:56 <msvb-lab> This is probably off topic though, so I'll shut up for now.
452 2014-04-09 06:39:43 <warren> msvb-lab: follow the gitian directions and do a build yourself and dissect the VM to learn how it works
453 2014-04-09 06:39:52 <warren> msvb-lab: enter the VM while it is running with on-target and poke around
454 2014-04-09 06:46:08 <msvb-lab> warren: Thanks for the tips. on-target is just the next step on my list of research.
455 2014-04-09 06:46:47 <msvb-lab> It seems that after a few things bootstrap a DSA private key is placed in a /var subdirectory which is used by on-target to connect to the KVM based VM.
456 2014-04-09 06:47:28 <msvb-lab> ...and that on LXC based builds SSH is not used to connect to the containers but some internal lxc-start thingy instead.
457 2014-04-09 06:47:45 <msvb-lab> Anyway, getting there little by little. Got to be patient.
458 2014-04-09 06:47:52 <msvb-lab> Thanks again for the tips.
459 2014-04-09 06:48:39 <warren> I don't know how functional LXC is right now.
460 2014-04-09 06:48:42 <warren> michagogo|cloud: is LXC usable now?
461 2014-04-09 07:05:04 <kdomanski> hmm, if I replace all of boost mutex stuff with std:: equivalents then I get a deadlock at shutdown
462 2014-04-09 07:05:06 <msvb-lab> warren: The Tor project is using gitian on VM guests no problem.
463 2014-04-09 07:05:39 <msvb-lab> And of course VM guests don't provide VT-x/AMD-V extensions, so the only way to go is LXC or equivalent (Solaris zones, etcetera) container system.
464 2014-04-09 07:06:03 <msvb-lab> ...and yes, it works perfectly. Am testing it on a variety of VMs right now.
465 2014-04-09 07:06:58 <msvb-lab> In fact, anyone interested in gitian using LXC (if it's not working for bitcoin) should walk around the corner to #tor-dev (irc.oftc.org) and ask there.
466 2014-04-09 07:08:22 <midnightmagic> warren: I'm using LXC.
467 2014-04-09 07:08:43 <fanquake> msvb-lab channel seems a bit empty?
468 2014-04-09 07:09:57 <msvb-lab> Huh, it's irc.oftc.net port 6697 TLS. Did you use freenode by mistake?
469 2014-04-09 07:13:26 <fanquake> yea just jumped in. Only two other in there.
470 2014-04-09 07:16:13 <msvb-lab> fanquake: What? No, there's something wrong. As you can imagine the Tor folks are very busy with the beading heart rodeo. There are several dozen people squirming in that room.
471 2014-04-09 07:17:46 <msvb-lab> Whoops got that as wrong as possible, meant Heartbleed of course.
472 2014-04-09 07:18:01 <fanquake> msvb-lab Yea I jumped in on freenode. Will join the proper chan in a sec.
473 2014-04-09 07:18:23 <msvb-lab> Which I would imagine affects Bitcoin core as well, unless you folks use PolarSSL or something other than OpenSSL.
474 2014-04-09 07:19:31 <gmaxwell> kdomanski: I would almost be surprised if we don't have a locking bug or two on shutdown still.
475 2014-04-09 07:19:45 <gmaxwell> kdomanski: so it may be that the other primitives are exposing some existing bug.
476 2014-04-09 07:20:35 <vetch> gmaxwell: you can't shut down properly / within a reasonable timeframe if you have a miner connected over RPC. sorta related.
477 2014-04-09 07:21:21 <vetch> related because I get impatient and ^Z and end up with a locked database
478 2014-04-09 07:22:04 <midnightmagic> namecoin still has a bug where if resendwallettransactions() takes longer than the delay before another trigger it'll never come back.
479 2014-04-09 07:25:27 <vetch> bitcoind: checkqueue.h:167: CCheckQueueControl<T>::CCheckQueueControl(CCheckQueue<T>*) [with T = CScriptCheck]: Assertion `pqueue->nTotal == pqueue->nIdle' failed.
480 2014-04-09 07:25:37 <vetch> that's an odd one.
481 2014-04-09 07:27:23 <wumpus> warren: please don't spread fud, the static executables have all hardening flags enabled except for -pie
482 2014-04-09 07:27:53 <warren> wumpus: yeah, that's what I totally misread
483 2014-04-09 07:27:56 <warren> wumpus: i'm sorry.
484 2014-04-09 07:57:54 <wumpus> does anyone know where the page went about reporting bitcoin security issues? (that mentions the bitcoin-security list) I can't find it anymore
485 2014-04-09 08:03:21 <Luke-Jr> wumpus: https://bitcoin.org/en/development
486 2014-04-09 08:04:12 <wumpus> strange, that one didn't turn up on google
487 2014-04-09 08:06:43 <kankles> just got error: {"code":-2,"message":"Safe mode: Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."}
488 2014-04-09 08:06:49 <kankles> on testnet
489 2014-04-09 08:07:23 <kankles> someone was mining like a block a second earlier.
490 2014-04-09 08:08:36 <vetch> heh
491 2014-04-09 08:08:37 <vetch> that's me
492 2014-04-09 08:08:54 <vetch> kankles: > 600 block reorg
493 2014-04-09 08:11:02 <vetch> hm. I seem to have killed Bitpay's insight with that.
494 2014-04-09 08:11:32 <kankles> what was you?
495 2014-04-09 08:12:03 <vetch> mm.
496 2014-04-09 08:12:19 <vetch> the network really, really hates reorganisations.
497 2014-04-09 08:14:06 <gmaxwell> vetch: hm?
498 2014-04-09 08:15:08 <vetch> gmaxwell: just things get sort of slow if you do multiple consecutive chains and reorg to them. my second test net node is struggling to keep up, Bitpay's Insight is having difficulty, blockexplorer.com isn't updating blocks anymore
499 2014-04-09 08:17:33 <vetch> gmaxwell: it's taken almost 10 minutes for my testnet node to reorg 500 blocks.
500 2014-04-09 08:19:00 <gmaxwell> vetch: if you just linked up a partitioned network, it doesn't try to reorg until the next block.
501 2014-04-09 08:21:38 <vetch> gmaxwell: the reorg triggered on the node, it's glacier slow with UpdateTip(). obviously not an issue just doesn't behave the way I expected.
502 2014-04-09 08:21:45 <vetch> gmaxwell: is there a technical limit that stops me from reorging 3700 blocks? it doesn't seem to like me doing that particularly much.
503 2014-04-09 08:24:32 <gmaxwell> vetch: nope and I've tested reorgs much larger than that.
504 2014-04-09 08:24:39 <vetch> REORGANIZE: Disconnect 3717 blocks; 0000000004ace122ee2d68d2814d9d8aeb3c93c9d536bd122f7f93bff5c6dda1..
505 2014-04-09 08:24:42 <vetch> REORGANIZE: Connect 0 blocks; ..0000000004ace122ee2d68d2814d9d8aeb3c93c9d536bd122f7f93bff5c6dda1
506 2014-04-09 08:24:46 <vetch> ERROR: DisconnectBlock() : undo data overwriting existing transaction
507 2014-04-09 08:24:48 <gmaxwell> I'm not sure why it's "glacier slow" any more info?
508 2014-04-09 08:26:10 <vetch> gmaxwell: I didn't have the debugging enabled, all I've got is that it was taking ~2 seconds per UpdateTip(). each block is practically empty so I'm not sure what it was doing.
509 2014-04-09 08:28:13 <midnightmagic> well.  the hashes look the same now for my gitian build but the form is weird.
510 2014-04-09 08:28:23 <gmaxwell> vetch: uh that sounds like your database was corrupt. Did you do any manually manipulation of the block files/undo files/ chainstate?
511 2014-04-09 08:29:40 <vetch> gmaxwell: https://github.com/sipa/bitcoin/commit/9fe9d788a9eaf40cc5dd1171807b24c9bd170104.patch < probably nowhere near enough sanity checking somewhere in that. I realise it'd 100% not meant for use.. anywhere.
512 2014-04-09 08:33:15 <kdomanski> gmaxwell: now that I think about it, C++11 locking might be simply unable to work properly with boost threads - I might need to cut out entire boost_thread before this works
513 2014-04-09 08:34:11 <midnightmagic> uh.
514 2014-04-09 08:34:23 <midnightmagic> has anyone done a ./bin/gverify for 0.9.1?
515 2014-04-09 08:41:12 <drizztbsd> hi, is there any other reason to upgrade to bitcoin 0.9.1?
516 2014-04-09 08:42:04 <wumpus> midnightmagic: yes, shows all OKs for me
517 2014-04-09 08:42:13 <midnightmagic> wumpus: Thanks.
518 2014-04-09 08:42:24 <midnightmagic> wumpus: I was building from the tag rather than the branch.
519 2014-04-09 08:42:49 <wumpus> midnightmagic: I did have to fetch the key for ttsda as he's a new signer, if you don't it will complain about a missing key
520 2014-04-09 08:43:02 <wumpus> midnightmagic: you should build from the tag (v0.9.1)
521 2014-04-09 08:43:25 <wumpus> the tag is immutable and signed, the branch isn't
522 2014-04-09 08:43:31 <midnightmagic> wumpus: I was getting a valid sig from gavin, and myself, but not from micha, tt..  wait what?
523 2014-04-09 08:43:33 <wumpus> though they currently point to the same commit
524 2014-04-09 08:44:02 <midnightmagic> Their release is 0.9.1, not v0.9.1
525 2014-04-09 08:44:29 <michagogo> cloud|Pong
526 2014-04-09 08:44:34 <midnightmagic> wumpus: Can you tell me about the form differences between asch/laan and the rest?
527 2014-04-09 08:44:40 <wumpus> if you check the release process, you'll see that the v${VERSION} is added
528 2014-04-09 08:44:48 <michagogo> cloud|midnightmagic: newer ruby = more new lines
529 2014-04-09 08:45:28 <wumpus> the gitian.sigs directory is called ${VERSION} or ${VERSION}-win, however the tag built from is v${VERSION}
530 2014-04-09 08:46:12 <midnightmagic> michagogo|cloud: What's your host OS?
531 2014-04-09 08:46:28 <michagogo> cloud|midnightmagic: which?
532 2014-04-09 08:46:46 <michagogo> cloud|warren: I built v0.9.1 with lxc
533 2014-04-09 08:46:52 <midnightmagic> michagogo|cloud: Where you did the gitian build. You had a host OS; I'm wondering how you get a newer ruby than I do.
534 2014-04-09 08:47:03 <midnightmagic> (I am also using lxc.)
535 2014-04-09 08:48:00 <wumpus> if you do the gitian build on Ubuntu 14.04 (host, the guest will of course be 12.04) you get the 'new ruby'
536 2014-04-09 08:48:06 <michagogo> cloud|midnightmagic: I do gbuilds in different places, depending on several factors
537 2014-04-09 08:48:27 <michagogo> cloud|My 0.9.1 sigs are from precise
538 2014-04-09 08:48:31 <warren> there's problems with a version of ruby?
539 2014-04-09 08:48:36 <wumpus> warren: no
540 2014-04-09 08:48:38 <wumpus> no problems
541 2014-04-09 08:48:39 <warren> gitian works for me with ruby 2.0.0 through 2.1.1
542 2014-04-09 08:48:42 <warren> oh ok
543 2014-04-09 08:48:49 <michagogo> cloud|warren: newer versions do YAML styling differently
544 2014-04-09 08:48:51 <wumpus> the yaml is pretty-printed differently
545 2014-04-09 08:49:00 <wumpus> but the content (if you parse it) it is the same
546 2014-04-09 08:49:04 <midnightmagic> warren: If the host is 12.04, the ruby chokes on the verify because the output of the gitian sign is incompatible.
547 2014-04-09 08:49:14 <warren> is that related to the sigs being formatted weird sometimes?
548 2014-04-09 08:49:21 <midnightmagic> yes.
549 2014-04-09 08:49:24 <warren> ahh
550 2014-04-09 08:49:43 <michagogo> cloud|So the older ruby can't parse the newer ruby's YAML?
551 2014-04-09 08:49:47 <michagogo> cloud|o_O
552 2014-04-09 08:49:51 <wumpus> crazy
553 2014-04-09 08:50:03 <warren> everyone should be using rbenv anywa
554 2014-04-09 08:50:05 <warren> anyway
555 2014-04-09 08:50:12 <warren> the ruby in my distro is buggy
556 2014-04-09 08:50:15 <jcorgan> n/cl
557 2014-04-09 08:50:16 <michagogo> cloud|rbenv?
558 2014-04-09 08:50:25 <warren> michagogo|cloud: the best way to run ruby
559 2014-04-09 08:50:31 <midnightmagic> Also, gavin's signature works whether I use release=0.9.1 or v0.9.1, but the others don't. My sig matches if I use v0.9.1 release, but not if I use 0.9.1 release. Using 0.9.1 everyones who doesn't have the newer ruby form, matches.
560 2014-04-09 08:50:40 <midnightmagic> 
ACTION is sad that ruby is being used.

561 2014-04-09 08:50:54 <warren> what would you prefer it be written in?
562 2014-04-09 08:50:57 <wumpus> midnightmagic: why cares, it works, no holy wars here
563 2014-04-09 08:51:02 <michagogo> cloud|midnightmagic: what do you have against ruby?
564 2014-04-09 08:51:09 <wumpus> please take this elsewhere
565 2014-04-09 08:51:21 <michagogo> cloud|Is rbenv the same kind of thing as RVM?
566 2014-04-09 08:51:35 <midnightmagic> ..  this isn't a holy war. I'm sad that in this particular case it is making it difficult for me to participate in the gitian build process. I have nothing against Ruby itself.
567 2014-04-09 08:51:36 <warren> I have nothing against ruby, I kind of dislike the OS though, there are better options for a long-term build environment.
568 2014-04-09 08:51:54 <michagogo> cloud|
ACTION uses RVM on unixy systems that he's actually using, which isn't many of them

569 2014-04-09 08:52:08 <midnightmagic> And an inability to verify by someone who is trying to gverify IMO is very on-topic.
570 2014-04-09 08:53:19 <wumpus> midnightmagic: don't blame the programming language for that, it's likely something with the yaml library,  there may even be an argument to pretty-print old-style
571 2014-04-09 08:54:18 <warren> if a particular version of the library works, can't you lock it with Gemfile.lock?
572 2014-04-09 08:55:24 <midnightmagic> wumpus: It's an issue with the fragility of the host OS build environment. Sure, I can and am working around this. My ultimate hashes do in fact match, regardless of the lies gverify is telling me.
573 2014-04-09 08:55:25 <wumpus> (not that I like the yaml choice in any case,  json would have been more interoperable, it was tricky to set up the python yaml parser to get them to work)
574 2014-04-09 08:55:59 <wumpus> (but that's yet another holy war for another day :p)
575 2014-04-09 08:56:54 <gmaxwell> there is a whole seperate spec for signed json data... because json by itself isn't great for being signed. :(
576 2014-04-09 08:57:16 <gmaxwell> https://datatracker.ietf.org/wg/jose/charter/
577 2014-04-09 08:57:25 <midnightmagic> I'd like to point out that I am not asking anyone else to flex or bend around me right now; *I* am doing the bending. The problem is my own. I'm just asking questions that will spare me a few hours of careful debugging and rebuilding so I can create a set of sigs that can ultimately be included in the canonical gitian.sigs
578 2014-04-09 08:57:46 <wumpus> gmaxwell: well in this case mutability isn't much of an issue, as the entire file is signed
579 2014-04-09 08:57:49 <warren> I'd like to rewrite gitian one day
580 2014-04-09 08:58:07 <gmaxwell> midnightmagic: your complaint above was externally indistuishable from a random language favortism gripe, at least to someone who knows you less well than I do.
581 2014-04-09 08:58:24 <midnightmagic> gmaxwell: That is why I clarified rather than gave up.
582 2014-04-09 08:59:09 <hearn> gmaxwell: lol. i think you’ve been reading too many crypto papers
583 2014-04-09 08:59:12 <warren> mm, i'm tired
584 2014-04-09 08:59:17 <hearn> “externally indistinguishable from random”?
585 2014-04-09 08:59:21 <wumpus> but it's interesting that thought went into the yaml choice, if it's better suited for signing it's a good choice
586 2014-04-09 08:59:23 <gmaxwell> hah
587 2014-04-09 09:00:37 <warren> 
ACTION sleep

588 2014-04-09 09:06:15 <wumpus> kdomanski: this is funny, gitian calls your branch name 'unsanitary' bin/gbuild:25:in `sanitize': unsanitary string in C++11 (RuntimeError)
589 2014-04-09 09:07:06 <wumpus> no problem, I'll just create a tracking branch with another name
590 2014-04-09 09:09:48 <midnightmagic> wumpus: You mentioned that the v$VERSION is added somewhere in the release process. Can you tell me where?
591 2014-04-09 09:10:11 <midnightmagic> Or..  can anyone tell me where.
592 2014-04-09 09:10:33 <michagogo> cloud|midnightmagic: release-process.md
593 2014-04-09 09:10:48 <michagogo> cloud|You export, for example, VERSION=0.9.1
594 2014-04-09 09:11:16 <michagogo> cloud|And then some places use v$VERSION and others use $VERSION
595 2014-04-09 09:11:38 <michagogo> cloud|If I recall correctly, the git checkout and the gbuild --commit line use v$VERSION
596 2014-04-09 09:11:40 <midnightmagic> ah. in the written copy-pasta-ish stuff then
597 2014-04-09 09:11:48 <michagogo> cloud|The signing destination dir uses $VERSION
598 2014-04-09 09:11:51 <kdomanski> wumpus: lol
599 2014-04-09 09:12:20 <michagogo> cloud|6:41:12 <warren> RHEL7 might be an excellent replacement for gitian VM, 10 years of support on a distro with gcc-4.8.2
600 2014-04-09 09:12:52 <gmaxwell> it's a bit annoying to need a whole OS in the builder VM.
601 2014-04-09 09:13:02 <michagogo> cloud|Is RHEL not a paid product?
602 2014-04-09 09:13:27 <midnightmagic> RHEL is a paid product, with an obfuscated kernel patchset.
603 2014-04-09 09:13:45 <michagogo> cloud|Also, does something like debootstrap exist for it?
604 2014-04-09 09:14:25 <midnightmagic> I *think* Oracle de-obfuscated it and originally was promising to continue to de-obfuscate it. I don't know what happened to that in the last six months or so.
605 2014-04-09 09:17:57 <Luke-Jr> I presume warren was thinking something like CentOS or SL which are just RHEL clones
606 2014-04-09 09:18:39 <midnightmagic> CentOS did not de-obfuscate the kernel patchset.
607 2014-04-09 09:18:49 <Luke-Jr> midnightmagic: relevance?
608 2014-04-09 09:19:55 <midnightmagic> Who knows what the kernel is doing?
609 2014-04-09 09:20:23 <midnightmagic> 10 years of support is nice though
610 2014-04-09 09:20:24 <hearn> de-obfuscate?
611 2014-04-09 09:20:32 <hearn> surely you mean it’s just not well documented or something?
612 2014-04-09 09:21:26 <midnightmagic> hearn: The kernel patchset for RHEL was converted from broken-out, purpose-specific patches (a few hundred or so I guess) into one giant nasty monolithic patch where inter-related patches are no longer individual. You must pay the subscriber fee to see the broken-out patchset.
613 2014-04-09 09:21:40 <gmaxwell> hearn: the past controversy was because they kept their own git repo private and then did only bulk code drops, not usable freestanding patches. Of course some companies do most of their opensource via codedrop... so.. ::shrugs::
614 2014-04-09 09:21:53 <midnightmagic> hearn: This was in retaliation for Oracle's fork.
615 2014-04-09 09:23:58 <hearn> right
616 2014-04-09 09:24:02 <hearn> so they just squashed their patch, basically
617 2014-04-09 09:24:32 <midnightmagic> And removed documenting nomenclature.
618 2014-04-09 09:25:02 <kdomanski> midnightmagic: I'd say they're just protecting their bussiness model
619 2014-04-09 09:25:45 <midnightmagic> kdomanski: Correct. And now it's hard to study what they've done; research that was easy before is now difficult without paying the ransom.
620 2014-04-09 09:28:08 <drizztbsd> from an italian newspaper: "The researchers called the problem "Heartbleed" (bleeding heart) because it involves the vital center of the encryption protocol that sends messages back and forth on the server."
621 2014-04-09 09:28:19 <drizztbsd> lol
622 2014-04-09 09:28:35 <Luke-Jr> kdomanski: DRM is protecting a business model too :P
623 2014-04-09 09:29:31 <hearn> drizztbsd: haha
624 2014-04-09 09:29:55 <kdomanski> can't blame someone for wanting a return on investment
625 2014-04-09 09:30:01 <hearn> i love how journalists manage to mangle things that are right on the front of a single page website that has the name of the story they’re writing about as its domain name
626 2014-04-09 09:30:09 <hearn> s/journalists/a few journalists/
627 2014-04-09 09:31:10 <kdomanski> of course DRM is a case of good managers applying irrelevant experience in a new and unforgiving envoronment
628 2014-04-09 09:33:01 <hearn> kdomanski: actually it can often be a sensible business decision.
629 2014-04-09 09:33:23 <hearn> kdomanski: there are plenty of case studies showing cost of DRM < savings from less piracy, for particular pieces of software
630 2014-04-09 09:33:45 <hearn> and i’ve heard from reliable sources the same is true, or has at times been true, in the movie business as well. though i haven’t seen those case studies myself
631 2014-04-09 09:33:56 <midnightmagic> Long as you're willing to push the costs onto your users, sure.
632 2014-04-09 09:36:33 <kdomanski> of course a good manager evaluates it case by case
633 2014-04-09 09:39:34 <kdomanski> when you can watch a movie online for a couple of µBTC, you're not going to bother with downloading a DRM-broken version from torrents
634 2014-04-09 09:40:33 <sipa> depends on the convenience
635 2014-04-09 09:40:44 <sipa> not necessarily on the price
636 2014-04-09 09:40:51 <kdomanski> true
637 2014-04-09 09:40:56 <Luke-Jr> Bitcoin makes it more convenient!
638 2014-04-09 09:41:05 <midnightmagic> comment, research, fair use, time-shifting, and archival purposes are not compatible with that approach.
639 2014-04-09 09:41:11 <warren> hearn: the patchsets were available to customers
640 2014-04-09 09:41:42 <midnightmagic> via a reeeealy slow web interface.
641 2014-04-09 09:41:42 <vetch> Luke-Jr: just you wait, somebody will start trying to stuff DRM tokens into your blockchain soon, though I've no idea why.
642 2014-04-09 09:41:43 <hearn> midnightmagic: some of them can be, actually
643 2014-04-09 09:41:48 <kdomanski> Electronic Arts succesfully pulled a few stunts where legal game buyers had to resort to downloading cracks
644 2014-04-09 09:42:00 <midnightmagic> hearn: I agree.
645 2014-04-09 09:42:01 <hearn> midnightmagic: Cinavia is a good example of fair use compatible DRM
646 2014-04-09 09:42:19 <vetch> kdomanski: yep. I had to download a crack for Spore because it's DRM was so restrictive that I couldn't play.
647 2014-04-09 09:42:40 <vetch> I literally had the disk in my hand but still couldn't play the damn thing.
648 2014-04-09 09:42:47 <hearn> PC DRM is a losing proposition because the playing field is too balanced. Console DRM works much better for all parties, because it was designed into the platform from the start
649 2014-04-09 09:42:51 <midnightmagic> ack, I hate Cinavia. Man that stuff is pernicious! :-)
650 2014-04-09 09:43:15 <kdomanski> ah, the pc master race
651 2014-04-09 09:43:28 <midnightmagic> gotta go.  i pushed my gitian sigs. I'd be very grateful if someone would tell me if they can gverify with my sigs.
652 2014-04-09 09:44:51 <kdomanski> gmaxwell: I surrender - there's no way to eliminate boost_thread without implementing an alternative for thread interruption - and std::thread doesn't have one
653 2014-04-09 09:45:46 <HectorJ> Hi all! I've been reading the bitcoin-core code and I wondered if you could explain me something : What is the reasoning behind the memlocking (cf allocators.h/.cpp)? Is the swap considered unsafe for keys, and why? (trying to learn)
654 2014-04-09 09:46:09 <sipa> HectorJ: you don't want private keys to end up on disk
655 2014-04-09 09:46:24 <sipa> HectorJ: someone could later extract them
656 2014-04-09 09:46:36 <Apocalyptic> that's a standard handling
657 2014-04-09 09:46:52 <HectorJ> isn't RAM also extractable?
658 2014-04-09 09:47:07 <kdomanski> not a few minutes after poweroff
659 2014-04-09 09:47:24 <sipa> HectorJ: yes, but if an attacker can acess your ram at the time of access itself, you're already doomed
660 2014-04-09 09:47:28 <vetch> HectorJ: if you're worried about physical access, you've already lost.
661 2014-04-09 09:48:18 <HectorJ> ok, I see. RAM isn't perfectly safe but way safer than swap. Makes sense
662 2014-04-09 09:48:45 <sipa> well, we assume ram perfectly safe
663 2014-04-09 09:49:09 <sipa> as there is nothing you can do without that assumption
664 2014-04-09 09:49:14 <HectorJ> If i understood well, heartbleed proves it's not always true
665 2014-04-09 09:49:18 <vetch> HectorJ: don't even have to shut a computer down if you steal it. you just get out your HotPlug Field Kit, swap the power source on the fly and attack it at your own comfort in another location. http://www.cru-inc.com/products/wiebetech/hotplug_field_kit/
666 2014-04-09 09:49:40 <sipa> HectorJ: that is not a provlem with the ram
667 2014-04-09 09:51:03 <vetch> they also sell a "mouse jiggler" usb mouse emulator to stop seized computers automatically locking and encrypting. creepy.
668 2014-04-09 09:51:04 <sipa> HectorJ: there are always different attack vectors
669 2014-04-09 09:51:35 <sipa> but if you assume an attacker has direct access to your memory, they could just overwrite your wallet code with something that leaks keys
670 2014-04-09 09:51:56 <gmaxwell> vetch: you don't use an accelerometer tamper switch?!
671 2014-04-09 09:52:15 <sipa> however, they may have access to the disk your system uses after the fact, but not while you are using it
672 2014-04-09 09:52:44 <sipa> that said, we're not consistently protecting against that use case either
673 2014-04-09 09:53:12 <sipa> mostly just a best effort protection... it likely makes things harder in practice
674 2014-04-09 09:54:05 <vetch> gmaxwell: I imagine after the first false trigger and the thermite disk destroyer messes up the data centre, they wouldn't be very keen to invite you back
675 2014-04-09 09:54:49 <vetch> in honestly I've never heard of accelerometers being used as a security device
676 2014-04-09 09:55:11 <HectorJ> sipa: thanks for the explanation... now I'm out to study the key encryption
677 2014-04-09 09:56:17 <sipa> HectorJ: actual keys are encrypted with aes using a master key, the master key itself is encrypted with a passphrase
678 2014-04-09 09:59:00 <HectorJ> you make it sound easy. I'm still going to look how it transposes into code
679 2014-04-09 09:59:39 <elichai2> sipa: ?
680 2014-04-09 09:59:42 <elichai2> here?
681 2014-04-09 09:59:57 <sipa> unfortunately, yes
682 2014-04-09 10:00:01 <elichai2> lol
683 2014-04-09 10:00:13 <elichai2> wait a sec, the block counter started moving again :)
684 2014-04-09 10:00:19 <elichai2> for now i'm ok :)
685 2014-04-09 10:00:33 <elichai2> (i'm in block 229190)
686 2014-04-09 10:00:58 <elichai2> but thx, if it will happen again i'll return :)