1 2015-01-12 00:56:02 <phantomcircuit> ggs
  2 2015-01-12 00:56:34 <phantomcircuit> anybody know whether d2i_ECDSA_SIG() calls ECDSA_SIG_new()
  3 2015-01-12 00:56:51 <sipa> seems unlikely
  4 2015-01-12 00:56:57 <sipa> but i don't knoe
  5 2015-01-12 00:57:00 <phantomcircuit> the docs seem to imply that it does
  6 2015-01-12 00:57:35 <phantomcircuit> and the parameter is ECDSA_SIG **sig
  7 2015-01-12 00:57:44 <phantomcircuit> which would imply it can do the allocation itself
  8 2015-01-12 00:58:33 <sipa> hmm
  9 2015-01-12 00:58:59 <sipa> you'll have to pipe the openssl code through a preprocessor
 10 2015-01-12 00:59:08 <sipa> if you need to find out
 11 2015-01-12 00:59:34 <phantomcircuit> i know
 12 2015-01-12 00:59:36 <phantomcircuit> but well
 13 2015-01-12 00:59:39 <phantomcircuit> do not want
 14 2015-01-12 01:00:01 <phantomcircuit> ECDA_verify calls ECDSA_SIG_new before d2i_ECDSA_SIG as we do
 15 2015-01-12 01:00:09 <phantomcircuit> but that just means they dont know either
 16 2015-01-12 01:04:55 <phantomcircuit> sipa, i guess i could also check by looking for memory leaks
 17 2015-01-12 01:16:26 <phantomcircuit> sipa, appears the docs are wrong
 18 2015-01-12 01:20:56 <gmaxwell> phantomcircuit: yea, in a super danerous way it seems. Looks to me like it does allocate, but only if the pointer is null.
 19 2015-01-12 01:21:28 <phantomcircuit> gmaxwell, the pointer or the dereferences pointer?
 20 2015-01-12 01:21:43 <gmaxwell> e.g. if you follow the documentation your software will depend on the content of uninitilized memory (a nice combination with a default compilation of openssl being completely valgrind unclean)
 21 2015-01-12 01:22:18 <gmaxwell> phantomcircuit: the pointer thats pointed to, if you just send in null for the outer pointer it returns right away.
 22 2015-01-12 01:22:55 <gmaxwell> If the pointer points to a null pointer, it appears to allocate. Assuming that I'm not getting thrown off by the source code obfscuation.
 23 2015-01-12 01:23:16 <gmaxwell> (I'd point you exactly where this happens but if I've decoded it wrong I don't want to spread my misunderstanding.)
 24 2015-01-12 01:24:08 <phantomcircuit> lol fun
 25 2015-01-12 01:24:09 <phantomcircuit>     d2i_ECDSA_SIG(&sig, &buffer, buf_len);
 26 2015-01-12 01:24:09 <phantomcircuit> sig = NULL;
 27 2015-01-12 01:24:12 <phantomcircuit> that works
 28 2015-01-12 01:24:22 <phantomcircuit> then ECDSA_SIG_free(sig);
 29 2015-01-12 01:24:30 <phantomcircuit> and d2i_ECDSA_SIG(&sig, &buffer, buf_len); still works
 30 2015-01-12 01:24:49 <phantomcircuit> presumably because it's still pointing to the same now freed memory
 31 2015-01-12 01:24:51 <gmaxwell> (I also confirmed my understanding by setting a breakpoint in a debugger and confirming the function I thought was being used was actually being used)
 32 2015-01-12 01:25:53 <gmaxwell> phantomcircuit: yup. You can confirm that the docs are wrong by sig = 1;  and watching it crash.
 33 2015-01-12 01:26:30 <sipa> that happens in several functions
 34 2015-01-12 01:26:43 <sipa> for convenience, it allocates the result for you
 35 2015-01-12 01:27:13 <gmaxwell> I wasn't aware that the function in question had docs, but I did go and read its source before acking the PR.
 36 2015-01-12 01:27:13 <sipa> but if you want it allocated elsewhere, you can pass a pointer to an existing one
 37 2015-01-12 01:27:35 <sipa> for example, if you want it allocated in a BN context
 38 2015-01-12 01:27:46 <phantomcircuit> gmaxwell, there is a single sentence
 39 2015-01-12 01:28:01 <gmaxwell> phantomcircuit: yea, I found it after someone said there was.
 40 2015-01-12 01:28:03 <phantomcircuit> it's under ECDSA_verify
 41 2015-01-12 01:28:13 <sipa> does it have a subject, an object, and a conjugated verb?
 42 2015-01-12 01:28:38 <phantomcircuit> sipa, i think it does!
 43 2015-01-12 01:28:49 <sipa> what else could one ask for?
 44 2015-01-12 01:29:05 <sipa> capitalization and punctuation?
 45 2015-01-12 01:29:38 <gmaxwell> sipa: that it actually describe the function in question?
 46 2015-01-12 01:30:17 <phantomcircuit> sipa, capitalization is off since the sentence starts with d2i_ECDSA_SIG
 47 2015-01-12 01:30:20 <gmaxwell> (or is just misinforming you in a way that you're unlikely to detect quickly good enough?)
 48 2015-01-12 01:30:29 <phantomcircuit> i think we can forgive them that error
 49 2015-01-12 01:31:53 <gmaxwell> the funny thing is that the 'fix' for this would be to make the code we have now leak memory; but arguably its the right thing to do, since it may be the case that existing callers are playing russian roulette with an uninitilized pointer.
 50 2015-01-12 01:37:21 <gmaxwell> I'd suggest we add an at startup test; but I think there is no way to test.
 51 2015-01-12 01:40:21 <gmaxwell> (well no portable, straight forward way)
 52 2015-01-12 01:41:21 <sipa> let's just ditch openssl?
 53 2015-01-12 01:41:26 <sipa> *ducks*
 54 2015-01-12 01:41:57 <gmaxwell> one step at a time
 55 2015-01-12 01:43:15 <phantomcircuit> gmaxwell, the only thing i can think of would be a child process that either works or segfaults
 56 2015-01-12 01:43:33 <phantomcircuit> ie the only way im aware of to actually check for cpu feature support
 57 2015-01-12 01:56:58 <gmaxwell> oh duh there is a simple way to test.
 58 2015-01-12 01:57:51 <gmaxwell> do a new(); then decode(); and check that the pointer didn't change. ... of course, there is some risk it changes to start reallocing things; but at least that test is conservative. at worse it could have a false positive of rejecting a change to reallocing that is otherwise safe.
 59 2015-01-12 02:00:59 <sipa> i do not expect this behaviour to change, it seems to be a general principle in their api
 60 2015-01-12 05:04:18 <dfletcher> hum you know it would be really useful to have blocknotify, walletnotify and alertnotify somehow be able to say if its testnet. cause what I seem to be stuck with is having the external program find and read bitcoin.conf, connect to RPC and getinfo(). blarg.
 61 2015-01-12 05:05:05 <dfletcher> oh wait does a bitcoin.conf in the testnet/ subdir work? been using the one in main Roaming\Bitcoin dir.
 62 2015-01-12 05:12:59 <dfletcher> also heh i found myself wishing today that testnet alerts would get sent regularly for testing
 63 2015-01-12 05:13:11 <dfletcher> like the old 11AM air raid siren test ;>
 64 2015-01-12 05:51:05 <gmaxwell> dfletcher: it runs whatever you want, just make what it runs have an extra argument.
 65 2015-01-12 06:00:26 <dfletcher> gmaxwell, yea I understand that and I have a --testnet flag for my program
 66 2015-01-12 06:00:32 <dfletcher> but this is not just for me!
 67 2015-01-12 06:00:42 <dfletcher> I want to *know* what network im on
 68 2015-01-12 06:00:52 <dfletcher> not be told from outside when someone forgot to change the configuration ;)
 69 2015-01-12 06:05:17 <dfletcher> I guess it wouldn't be totally awful. it won't be able to look up the walletnotify tx or the blocknotify block. alerts though heh there is nothing to identify it with I think
 70 2015-01-12 06:06:11 <dfletcher> still that's pretty weakass. much better to just have bitcoind tell me whats up
 71 2015-01-12 06:06:16 <dfletcher> ima code it up
 72 2015-01-12 06:21:11 <copumpkin> are there mac builds of 0.10rc1 up anywhere?
 73 2015-01-12 07:27:51 <earlz> So, I'm having trouble with some of the bitcoin code. specifically the intepreter flags
 74 2015-01-12 07:28:06 <earlz> for instance, SCRIPT_VERIFY_DERSIG
 75 2015-01-12 07:28:26 <earlz> does it being set to 1 mean it would be disabled or enabled?
 76 2015-01-12 08:20:03 <wumpus> earlz: do you come from a EE background perhaps? in programming, 1/true almost always means active
 77 2015-01-12 08:20:50 <nii236> wumpus, in EE it could be either depending on the usage of the digital IO
 78 2015-01-12 08:21:00 <wumpus> nii236: exactly
 79 2015-01-12 08:21:58 <nii236> Mostly so you can tell the difference between power loss and healthy state
 80 2015-01-12 08:32:32 <wumpus> although here too, it can grow that way that flags have an inverted meaning, but in that case it will be explicit from the name, e.g. SCRIPT_DISABLE_DERSIG. The assumption still is flag 1 = enabled unless stated otherwise.
 81 2015-01-12 08:34:50 <nii236> Ah ok
 82 2015-01-12 08:35:58 <wumpus> but indeed, in EE there can be much more structural reasons for active-low
 83 2015-01-12 08:38:49 <nii236> Usually related to safety
 84 2015-01-12 08:38:56 <nii236> Software is less likely to explode
 85 2015-01-12 08:49:32 <wumpus> software only explodes in complexity
 86 2015-01-12 08:50:56 <wumpus> I've backported the DER robustness fix, I'm going to tag 0.9.4 on the 0.9 branch in a minute
 87 2015-01-12 08:55:50 <jonasschnelli> needs "upstream" tag https://github.com/bitcoin/bitcoin/issues/5260
 88 2015-01-12 09:02:37 <wumpus> done, thanks
 89 2015-01-12 09:37:34 <maaku> well there is opcode HCF -- halt and catch fire :)
 90 2015-01-12 09:48:53 <wumpus> maaku: contingent on the Intel Thermite(TM) extensions coprocessor?
 91 2015-01-12 09:59:08 <wumpus> 0.9.4 release notes, additions/corrections welcome https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md
 92 2015-01-12 10:01:42 <michagogo> Hm, I hope I still have the 0.9 deps around
 93 2015-01-12 10:02:09 <wumpus> you need to rebuild a lot of them anyway (e.g. openssl bump)
 94 2015-01-12 10:02:29 <wumpus> well, not really a lot of them, but some of them
 95 2015-01-12 10:04:03 <wumpus> a qt rebuild for linux and windows could luckily be avoided
 96 2015-01-12 10:05:25 <michagogo> copumpkin: Bitcoin.org/bin
 97 2015-01-12 10:05:45 <wumpus> michagogo: he already left before anyone could answer
 98 2015-01-12 10:05:50 <michagogo> wumpus: right, annoying that we combine most of the deps in 1
 99 2015-01-12 10:05:52 <michagogo> wumpus: Ah
100 2015-01-12 10:06:30 <michagogo> At least I don't have to do qt for win, which is arguably the worst part
101 2015-01-12 10:06:36 <wumpus> michagogo: well the annoying part is that qt depends on openssl, in the case of windows and linux that resulted in no changes to the intermediate libraries, but the macosx intermediates are not deterministic on 0.9
102 2015-01-12 10:06:45 <michagogo> wumpus: right, I remember that
103 2015-01-12 10:07:19 <michagogo> Hm, does 0.9 linux 32-bit get built in the precise-amd64 target yet?
104 2015-01-12 10:07:31 <michagogo> Or do we still use an i386 for that?
105 2015-01-12 10:08:05 <wumpus> for 0.9 that's still built on a 32-bit VM IIRC
106 2015-01-12 10:09:40 <michagogo> Damn. I guess I have a new VM to build.
107 2015-01-12 10:10:24 <michagogo> (I deleted mine the other day when trying to troubleshoot gitian on my upgraded-to-trusty VM)
108 2015-01-12 10:10:32 <wumpus> well most important 0.9.4 will be the PPAs and distros, gitian users of 0.9.3 don't *need* to upgrade (although there are a few small fixes in there)
109 2015-01-12 10:10:46 <michagogo> (Only to figure out that I just needed to switch to lxc-execute)
110 2015-01-12 10:11:33 <michagogo> wumpus: btw, do you know tar well? I think cfields's change to fix the nested cache thing broke it, or something
111 2015-01-12 10:12:05 <wumpus> hm? what is broken? haven't updated gitian in a while
112 2015-01-12 10:12:08 <michagogo> I commented with the error in the PR:, I think it was #94 or 97 or something in gitian-builder
113 2015-01-12 10:12:28 <wumpus> everytime I do that, some use case of me is broken :)
114 2015-01-12 10:12:33 <michagogo> wumpus: take a look at the recent commits
115 2015-01-12 10:13:06 <michagogo> Gbuild was copying the cache at the end of the build to cache/cache/ instead of cache/
116 2015-01-12 10:13:24 <michagogo> cfields tweaked the copy-from-host script
117 2015-01-12 10:13:38 <michagogo> But now I'm getting errors about files existing :/
118 2015-01-12 10:13:42 <wumpus> golden gitian-builder commit for me is: c834f37  I've built both 0.10 and 0.9 with that recently
119 2015-01-12 10:14:16 <michagogo> wumpus: what changed from there to master? (On phone atm, not easy to look it up)
120 2015-01-12 10:14:23 <wumpus> for 0.9, you don't need any of the cache stuff anyhow
121 2015-01-12 10:14:32 <wumpus> michagogo: I don't know. I'm just careful to upgrade.
122 2015-01-12 10:15:10 <wumpus> for part because I haven't had time to go over the changes since
123 2015-01-12 10:15:38 <michagogo> 
ACTION tries to remember if the GH url syntax is this: https://github.com/devrandom/gitian-builder/compare/c834f37...master

124 2015-01-12 10:16:03 <michagogo> Yep, got it
125 2015-01-12 10:16:12 <michagogo> wumpus: looks like you're using latest, except for that one fix
126 2015-01-12 10:16:39 <michagogo> If you use cache, I expect you'll see that the cache is copied in from cache/, but then copied out into cache/cache/
127 2015-01-12 10:17:07 <michagogo> You're one commit behind, that commit is cfields's fix for that issue
128 2015-01-12 10:18:52 <wumpus> michagogo: I'm sure I'll stumble on that as soon as we'll need to build 0.10rc2
129 2015-01-12 10:19:32 <michagogo> wumpus: yeah, workaround is just to copy everything from cache/cache/ to cache/
130 2015-01-12 10:20:00 <michagogo> When I get to my computer I'll try reverting that and seeing if that fixes the tar error
131 2015-01-12 10:21:10 <wumpus>  * [new tag]         v0.9.4 -> v0.9.4
132 2015-01-12 10:22:05 <michagogo> Cool
133 2015-01-12 10:22:29 <michagogo> 
ACTION waits for the sms, and in the meantimes gets up to get the computer running

134 2015-01-12 10:29:47 <michagogo> -s
135 2015-01-12 10:37:28 <michagogo> wumpus: leaving it open until there's a better solution?
136 2015-01-12 10:38:03 <wumpus> michagogo: yes, people are still working on the block timeouts
137 2015-01-12 10:39:13 <michagogo> 
ACTION waits for make-base-vm --lxc --suite precise --arch i386 to complete

138 2015-01-12 10:40:07 <wumpus> but due to the openssl update issue I want to tag 0.10.0rc2 today
139 2015-01-12 10:40:40 <michagogo> wumpus: which depends packages will be rebuilt?
140 2015-01-12 10:40:55 <wumpus> michagogo: the ones whose vX is bumped
141 2015-01-12 10:41:19 <michagogo> ...will it trip qt because it depends on openssl even though we know it doesn't affect it?
142 2015-01-12 10:41:28 <wumpus> I have no clue
143 2015-01-12 10:41:41 <michagogo> (I mean for 0.10 here, not 0.9)
144 2015-01-12 10:42:09 <wumpus> oh, I suppose it will
145 2015-01-12 10:42:27 <michagogo> Was cfields in UTC-10?
146 2015-01-12 10:42:40 <michagogo> Oh, no, that was warren
147 2015-01-12 10:42:44 <wumpus> 'even though we know...' information unfortunately doesn't figure into it if you make the software entirely autonomous :-)
148 2015-01-12 10:42:52 <michagogo> wumpus: yeah. :-/
149 2015-01-12 10:43:11 <wumpus> still, better to give the CPU some more work than developers
150 2015-01-12 10:43:24 <michagogo> I wonder if there's a way to poke it and tell it not to rebuild
151 2015-01-12 10:44:35 <michagogo> I think we could do it if it were just `make`'s detection method, but I don't know what we're doing
152 2015-01-12 10:45:08 <wumpus> the thing is, you need to build once to figure out that the result stays the same; something you can communicate to other people, but it can't work in a self-contained setup
153 2015-01-12 10:45:20 <michagogo> Right
154 2015-01-12 10:45:35 <wumpus> also: I verified for 0.9. I did not verify the same for 0.10's deps, it may be different there
155 2015-01-12 10:46:03 <michagogo> Actually, are the 0.10 deps deterministic?
156 2015-01-12 10:46:11 <wumpus> yes
157 2015-01-12 10:48:29 <wumpus>  * [new tag]         v0.10.0rc2 -> v0.10.0rc2
158 2015-01-12 11:15:59 <xabbix__> et). Turns out bitcoind does not do any verification or disconnects these dummy connections and therefore other, valid nodes in the network cannot connect to the node I raised. It would take just a few minutes for an attacker to write a simple code that gets the full node list from getaddr.bitnodes.io and automatically generates thousands of connections to each. I know this won't disconnect already connected nodes, however I bel
159 2015-01-12 11:15:59 <xabbix__> Guys, a few days ago I raised a concern regarding the amount of connections each full node can receive and the ability to exploit this limit to create a DoS attack on full nodes. gmaxwell didn't really think it was a big deal, but I did a small POC and started a full node locally, as soon as it started I ran a script that opens hundreds of connections to port 8333 and just listens (I'm using a simple socket connection, e.g. teln
160 2015-01-12 11:16:00 <xabbix__> ieve it could create a disturbance in the service for SPV clients or even new nodes trying to sync.
161 2015-01-12 11:30:26 <midnightmagic> Global connection exhaustion is a well-known attack vector.
162 2015-01-12 11:32:13 <xabbix__> I know I'm not the first to raise this, but with pretty cheap hardware I think an attacker could cause a real disruption of service.
163 2015-01-12 11:34:39 <midnightmagic> Was bitcoind consuming more than an expected amount of resources dealing with the mass influx of connections?
164 2015-01-12 11:35:08 <gdm85> I am going to build this rc2 for all 3 OSes
165 2015-01-12 11:36:33 <michagogo> gdm85: +1
166 2015-01-12 11:36:52 <xabbix__> midnightmagic, Haven't checked yet. Will check
167 2015-01-12 11:36:53 <midnightmagic> michagogo: did you have issues verifying sig for OSX?
168 2015-01-12 11:37:00 <michagogo> midnightmagic: hmm?
169 2015-01-12 11:37:11 <michagogo> what do you mean?
170 2015-01-12 11:37:37 <midnightmagic> michagogo: I built 0.10.0rc1 for OSX but it doesn't seem to verify the contents of the result.
171 2015-01-12 11:38:09 <midnightmagic> like, I'm getting different results than you guys apparently did.
172 2015-01-12 11:38:38 <michagogo> midnightmagic: Hm, that's weird
173 2015-01-12 11:38:48 <michagogo> Looking at gitian.sigs it seems that we all match
174 2015-01-12 11:39:03 <michagogo> (other than the source tarball, but that's a known issue and should be fixed already)
175 2015-01-12 11:39:18 <michagogo> Do you mismatch on all 4 hashes?
176 2015-01-12 11:39:26 <midnightmagic> michagogo: even Luke's?
177 2015-01-12 11:39:44 <midnightmagic> I mismatch on .dmg, .tar.gz and -osx64.tar.gz
178 2015-01-12 11:39:48 <michagogo> midnightmagic: yes
179 2015-01-12 11:39:54 <michagogo> His is just formatted differently
180 2015-01-12 11:40:08 <michagogo> Using a different ruby version, I think
181 2015-01-12 11:40:29 <michagogo> midnightmagic: do your inputs match?
182 2015-01-12 11:40:46 <michagogo>     3aa94bd248f6c0944acb57acfa9afb850ea8b991efaba4dc26befaf04760d92e  bitcoin-osx-0.10-desc.yml
183 2015-01-12 11:40:46 <michagogo> and     git:4e0bfa581438a662147fe4459522b308406d7f57 bitcoin'
184 2015-01-12 11:40:47 <midnightmagic> luke's sig matches for me too, just before I didn't have his key installed on my keyring.
185 2015-01-12 11:41:53 <midnightmagic> git:4e0bfa581438a662147fe4459522b308406d7f57 bitcoin'
186 2015-01-12 11:42:16 <michagogo> okay, and the descriptor?
187 2015-01-12 11:42:18 <midnightmagic> 3aa94bd248f6c0944acb57acfa9afb850ea8b991efaba4dc26befaf04760d92e  bitcoin-osx-0.10-desc.yml
188 2015-01-12 11:42:22 <michagogo> Hmmm
189 2015-01-12 11:42:25 <michagogo> That's weird
190 2015-01-12 11:42:34 <michagogo> What's your setup? (OS, host, VM, etc)
191 2015-01-12 11:42:39 <midnightmagic> are yu using LXC too?
192 2015-01-12 11:42:44 <michagogo> I am, yes
193 2015-01-12 11:43:02 <midnightmagic> 12.04 host, with the updated HWE kernel (3.13.0-43-generic)
194 2015-01-12 11:43:32 <sipa> hwe?
195 2015-01-12 11:43:34 <michagogo> If your host is Ubuntu, why not just use kvm?
196 2015-01-12 11:43:41 <michagogo> sipa: hardware enablement I think
197 2015-01-12 11:43:43 <midnightmagic> Ubuntu's 12.04 kernel was deprecated and required an update.
198 2015-01-12 11:44:21 <michagogo> https://wiki.ubuntu.com/1204_HWE_EOL
199 2015-01-12 11:44:25 <midnightmagic> (which appears to have broken some things including *some* types of LXC guests)
200 2015-01-12 11:45:10 <jonasschnelli> for gitian signing: i simply use a std. gpg key?
201 2015-01-12 11:45:16 <michagogo> jonasschnelli: yep
202 2015-01-12 11:45:23 <jonasschnelli> michagogo, thanks
203 2015-01-12 11:45:26 <midnightmagic> michagogo: Do you know offhand what your LXC guest config was? did it use the precise-amd64 flavour?
204 2015-01-12 11:45:36 <michagogo> midnightmagic: what do you mean?
205 2015-01-12 11:45:57 <michagogo> 0.10.0 is built in a precise-amd64 guest, yes
206 2015-01-12 11:46:02 <michagogo> that's enforced by the descriptor
207 2015-01-12 11:46:02 <midnightmagic> thanks.
208 2015-01-12 11:46:27 <michagogo> midnightmagic: But if you're running on an Ubuntu realhost, you're probably better off using kvm
209 2015-01-12 11:47:02 <midnightmagic> i like being able to attach directly into the container
210 2015-01-12 11:47:30 <michagogo> Is that better than sshing into the vm?
211 2015-01-12 11:47:54 <midnightmagic> it's certainly easier. it also helps debugging when ssh is broken.
212 2015-01-12 11:48:10 <midnightmagic> or, like in my case, the network interface fails.
213 2015-01-12 11:48:20 <michagogo> got it
214 2015-01-12 11:48:24 <jgarzik> wumpus, 0.10 needs 2a3d988b802dcea4453241e37168d8511078940a and a089c50981e822014ffc18e8a37b3518feb52206
215 2015-01-12 11:48:26 <jgarzik> 
ACTION resends

216 2015-01-12 11:48:39 <wumpus> too late
217 2015-01-12 11:49:06 <michagogo> midnightmagic: also, does your cache match?
218 2015-01-12 11:49:26 <michagogo> wumpus jgarzik: those are already in
219 2015-01-12 11:49:27 <michagogo> https://github.com/bitcoin/bitcoin/commit/06fdf326d38b02efba0ebafa4be59b4ac062c092
220 2015-01-12 11:49:51 <jgarzik> michagogo, wumpus did not list them as being on the 0.10 branch
221 2015-01-12 11:50:24 <wumpus> I did: - 06fdf32 bitcoin-tx: Fix JSON validation of prevtxs
222 2015-01-12 11:50:37 <midnightmagic> michagogo: what do you mean my cache?
223 2015-01-12 11:50:49 <michagogo> midnightmagic: see the end of the assert
224 2015-01-12 11:50:52 <wumpus>  in that commit message:   Github-Pull: #5528     Rebased-From: 2a3d988b802dcea4453241e37168d8511078940a a089c50981e822014ffc18e8a37b3518feb52206 2c14d1532fe66a243cdbfb7de48b298213305765
225 2015-01-12 11:51:25 <midnightmagic> oh. yea.
226 2015-01-12 11:51:29 <midnightmagic> well.
227 2015-01-12 11:51:48 <michagogo> wumpus: did release notes get updated for rc2?
228 2015-01-12 11:51:55 <wumpus> michagogo: no, feel like doing that?
229 2015-01-12 11:52:29 <michagogo> wumpus: is it just adding the commits from your email?
230 2015-01-12 11:52:42 <midnightmagic> difference are: MacOSX10.7.sdk.tar.gz cpio_2.11-7ubuntu3_amd64.deb vs cpio_2.11-7ubuntu3.1_amd64.deb, mime-support_3.51-1ubuntu1_all.deb vs mime-support_3.51-1ubuntu1.1_all.deb, python2.7-minimal_2.7.3-0ubuntu3.5_amd64.deb vs python2.7-minimal_2.7.3-0ubuntu3.6_amd64.deb and python2.7_2.7.3-0ubuntu3.5_amd64.deb and python2.7_2.7.3-0ubuntu3.6_amd64.deb.
231 2015-01-12 11:53:09 <michagogo> midnightmagic: the SDK being different is fine
232 2015-01-12 11:53:13 <wumpus> michagogo: I think so, and adding the OpenSSL warning from 0.9.4's release notes https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md
233 2015-01-12 11:53:24 <michagogo> And the .debs are probably also fine
234 2015-01-12 11:53:25 <wumpus> michagogo: ah no, scrap that
235 2015-01-12 11:53:33 <wumpus> there's no previous 0.10 release :P
236 2015-01-12 11:53:43 <michagogo> midnightmagic: look at the cache section, not base
237 2015-01-12 11:53:57 <michagogo> midnightmagic: wait, what gitian version are you using?
238 2015-01-12 11:54:11 <michagogo> wumpus: I'll see if I can figure out where they all go
239 2015-01-12 11:54:19 <midnightmagic> michagogo: yes, aside from the bitcoin built results, the above are the only results from a diff -r between fanquake's assert and mine
240 2015-01-12 11:54:37 <michagogo> hmmmm
241 2015-01-12 11:54:40 <michagogo> Odd.
242 2015-01-12 11:54:41 <midnightmagic> 2bcc06e6b75b3f7a0167cde7237331757dd559c6
243 2015-01-12 11:54:55 <michagogo> Maybe if you uploaded your results cfields could take a look at them and see what's different
244 2015-01-12 11:55:00 <midnightmagic> which is head from https://github.com/devrandom/gitian-builder.git. which commitid are you on
245 2015-01-12 11:55:08 <fanquake> What’s this?
246 2015-01-12 11:55:20 <michagogo> midnightmagic: yeah, latest here too
247 2015-01-12 11:55:30 <midnightmagic> fanquake: sorry, didn't mean to highlight you, I'm tracking down why my OSX gitian is failing
248 2015-01-12 11:55:37 <michagogo> fanquake: midnightmagic is mismatching on 0.10.0rc1 OS X for some reason
249 2015-01-12 11:56:03 <fanquake> eh, no worries.
250 2015-01-12 11:56:14 <fanquake> Am building rc2 atm.
251 2015-01-12 11:58:26 <midnightmagic> the other build results all match.
252 2015-01-12 11:59:01 <midnightmagic> michagogo: can you tell me the sha2 of xcode4630916281a.dmg for you?
253 2015-01-12 11:59:07 <michagogo> of what now?
254 2015-01-12 11:59:23 <michagogo> wumpus: should I branch off and PR to 0.10?
255 2015-01-12 11:59:25 <midnightmagic> the origin .dmg file from which you extracted the MacOSX SDK subdir
256 2015-01-12 11:59:35 <wumpus> michagogo: yes
257 2015-01-12 11:59:54 <michagogo> midnightmagic: no, sorry, I can't -- I'm not at the Mac (one of my parents', I think) that I used to get that
258 2015-01-12 12:00:06 <michagogo> and I don't know if the file is still there
259 2015-01-12 12:00:31 <midnightmagic> well. if someone still has their .dmg can they tell me if this matches: SHA256 (xcode4630916281a.dmg) = 07c454db2e7b09c7607df33b2d1d7cd3b04cdd9dfcbf9719db0bd0b0e310b69f
260 2015-01-12 12:01:17 <fanquake> midnightmagic 07c454db2e7b09c7607df33b2d1d7cd3b04cdd9dfcbf9719db0bd0b0e310b69f
261 2015-01-12 12:01:30 <midnightmagic> dangit
262 2015-01-12 12:01:42 <midnightmagic> i'll start over, try again.
263 2015-01-12 12:02:15 <wumpus> strange indeed
264 2015-01-12 12:02:26 <jonasschnelli> probably this is more important? not? SHA256(/Users/jonasschnelli/Desktop/MacOSX10.7.sdk.tar.gz)= bee9ed9dfc0daabd04f7860b9ff063ff7be58fe54a9b3df326944e690ed4fdb0
265 2015-01-12 12:02:31 <michagogo> jonasschnelli: no
266 2015-01-12 12:02:36 <michagogo> those are different for everyone
267 2015-01-12 12:02:49 <michagogo> that tgz isn't included in the dmg, it's tarred up from a dir in there
268 2015-01-12 12:02:53 <jonasschnelli> michagogo, because of the tar.gz algo?
269 2015-01-12 12:02:55 <michagogo> and it's not done deterministically
270 2015-01-12 12:03:07 <michagogo> I mean, it probably would be possible to do, but we don't bother
271 2015-01-12 12:03:33 <midnightmagic> jonasschnelli: those are different unless we could arrive at a deterministic tarball, since we're all tar'ing up differently
272 2015-01-12 12:03:44 <wumpus> tar includes usernames, dates, times, userids, permissions, can have different sort order of files
273 2015-01-12 12:03:46 <jonasschnelli> michagogo, hmm... so how could one make sure it was not manipulated from (xcode4630916281a.dmg) = 07c454db2e7b09c7607df33b2d1d7cd3b04cdd9dfcbf9719db0bd0b0e310b69f?
274 2015-01-12 12:03:55 <wumpus> it's possible to normalize them, but indeed, we don't
275 2015-01-12 12:03:57 <michagogo> jonasschnelli: hmm?
276 2015-01-12 12:04:04 <michagogo> That's the file that comes from Apple
277 2015-01-12 12:04:09 <michagogo> That's the same for everyone
278 2015-01-12 12:04:16 <midnightmagic> jonasschnelli: mostly by arriving at the same end-gitian
279 2015-01-12 12:04:19 <michagogo> Then each person who does the building pulls the SDK out of there
280 2015-01-12 12:04:31 <michagogo> And then, yeah, we should all get the same result
281 2015-01-12 12:04:35 <jonasschnelli> Okay. a different MacOSX10.7.sdk.tar.gz would end up in different gitian signatures.. okay.
282 2015-01-12 12:04:53 <michagogo> jonasschnelli: well, if it's different in a way that affects the build
283 2015-01-12 12:04:55 <michagogo> But yes
284 2015-01-12 12:05:45 <jonasschnelli> bip32: is there a best practice of how to create and store the bip32 master key?
285 2015-01-12 12:06:37 <wumpus> create: generate it randomly using secure randomness
286 2015-01-12 12:06:38 <fanquake> jonasschnelli while your around. Was going to tell you, I’m going tp update the osx build instructions so that people start building with qt5
287 2015-01-12 12:07:05 <wumpus> store: preferably store it encrypted with a passphrase
288 2015-01-12 12:07:24 <wumpus> e.g in the same way current wallet keys are stored
289 2015-01-12 12:07:45 <jonasschnelli> fanquake, Yes. Would be good. There should be bold letters telling something like "building with <Qt5 will result in a broken UX"
290 2015-01-12 12:08:47 <fanquake> Yep. I’ll make it clear that qt5 is really preffered. Few other little fixes for the instructions as well.
291 2015-01-12 12:09:47 <wumpus> fanquake: right, good to mention it, but it is also nothing bitcoin core-specific. qt4 just interacts badly with recent OSX
292 2015-01-12 12:09:48 <jonasschnelli> wumpus, but for receiving only a bip32 master pub key would be enough?
293 2015-01-12 12:10:15 <wumpus> jonasschnelli: if you use non-hardened derivation, yes, but that's a pit of snakes
294 2015-01-12 12:10:30 <michagogo> wumpus: I'll also pull release-notes.md from v0.9.4 as release-notes/release-notes-0.9.4.md
295 2015-01-12 12:10:55 <jonasschnelli> fanquake, and mention that building with Qt5 will also produce output perfectly runnable on non-retina macs
296 2015-01-12 12:11:41 <wumpus> jonasschnelli: so for *public* derivation, you can have a parent public key and derive child public keys for receiving
297 2015-01-12 12:11:50 <wumpus> jonasschnelli: for private/hardened derivation, that's not possible