1 2012-08-27 00:00:34 <ne0futur> the problem was a NULL tun variable,
2 2012-08-27 00:00:35 <ne0futur> immediate check for !tun
3 2012-08-27 00:00:38 <ne0futur> read it all
4 2012-08-27 00:00:45 <ne0futur> un unexploitable bug
5 2012-08-27 00:01:23 <ne0futur> well anyway lets say i m wrong i wont even try to argue
6 2012-08-27 00:01:35 <ne0futur> lets trust redhat and the nsa :p
7 2012-08-27 00:02:16 <ne0futur> A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :)
8 2012-08-27 00:02:25 <devrandom> sipa: there is a brctl command in the README.md ... you need br0
9 2012-08-27 00:02:26 <gmaxwell> ne0futur: the check happened _after_ the dereference. This is a clear violation of the C spec, it's undefined behavior. Yes, it's a bit subtle, but there are lots of ways to have subtle bugs.
10 2012-08-27 00:02:58 <gmaxwell> ne0futur: it's only 'unexplotable when viewed at the source level' by someone who does not have a firm grasp of the fine rules of C.
11 2012-08-27 00:03:01 <sipa> devrandom: i should have RTFM
12 2012-08-27 00:03:34 <devrandom> np
13 2012-08-27 00:03:47 <Arnavion> I seem to recall the Clang team complaining about that thing in the kernel
14 2012-08-27 00:03:54 <Arnavion> Using a variable first, checking if it's null later
15 2012-08-27 00:04:10 <Arnavion> and that they had to special-case removing the optimization in their compiler for the kernel
16 2012-08-27 00:05:03 <gmaxwell> Arnavion: The kernel developers aren't actually writing in C. They're writing in kernel-c. It's an imaginary language that is implemented by a compiler which tranliterates C-like code to asm and which exists only in the minds of the kernel develoepers.
17 2012-08-27 00:08:47 <ne0futur> gmaxwell: and the good gcc version
18 2012-08-27 00:09:08 <sipa> yes, it's a rapedly evolving language
19 2012-08-27 00:09:14 <sipa> *rapidly
20 2012-08-27 00:09:32 <gmaxwell> it doesn't really matter 'the gcc version' there are many compilers which will optimize out a redundant null check.
21 2012-08-27 00:09:49 <gmaxwell> E.g. the intel compiler and the power64 compiler will both do that. I think the intel one will even do it at O1.
22 2012-08-27 00:11:17 <genjix> ne0futur: sorry but that's undefined behaviour.
23 2012-08-27 00:11:21 <gmaxwell> Many C developers make a mistake of thinking of C like a preprocessor stage on an assembler??? Which is pretty much what the PDP11 DMR c compiler was, and thats how it's often taught to people. But that isnt how C is specified, and it's not how any modern compiler works.
24 2012-08-27 00:11:35 <Arnavion> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html There it is
25 2012-08-27 00:11:58 <ne0futur> still a security problem opened by the compiler
26 2012-08-27 00:12:29 <gmaxwell> ne0futur: no, it's a security problem opened by the incorrect code. In userspace code that code would reliably crash, but the kenel doesn't have the same memory protection as userspace.
27 2012-08-27 00:13:19 <genjix> Arnavion's link is good for explaining why.
28 2012-08-27 00:15:17 <genjix> tbh i prefer a compiler that produces binaries that fail hard and fast (or even better: don't run) with code that has undefined behaviour
29 2012-08-27 00:16:03 <genjix> c/c++ make no guarantees about how a binary with UB should behave. it can produce binaries that do absolutely anything.
30 2012-08-27 00:16:18 <kjj> C gets even stranger when you factor in the crazy things CPUs do. compilers are only the first step
31 2012-08-27 00:16:45 <gmaxwell> genjix: varrious bits of static analysis will happily point out that the code there suggests undefined behavior, so thats helpful. Unfortunately the compiler can't usually tell the difference between a boobytrap an an important operation.
32 2012-08-27 00:17:23 <gmaxwell> kjj: er. No. C specifies an abstract machine. If you write valid C your code will operate idetically on all correct implementations; because defined code is require to operate identically to the behavior of the abstract machine.
33 2012-08-27 00:17:47 <sipa> devrandom: sudo: unable to resolve host alduin
34 2012-08-27 00:17:54 <gmaxwell> (including widly different ones like ones where char is 16 bits or where arithemetic is ones compliment)
35 2012-08-27 00:17:59 <kjj> yeah, but the way a real machine operates is crazy odd compared to how we see that abstract machine in our heads
36 2012-08-27 00:17:59 <sipa> devrandom: that being the name of the host machine
37 2012-08-27 00:18:07 <genjix> gmaxwell: did you see that you're on bash.org?
38 2012-08-27 00:18:27 <sipa> kjj: sure, but at least that's (at least in sane cases) unobservable
39 2012-08-27 00:18:32 <sipa> except by timing
40 2012-08-27 00:18:46 <kjj> sipa: supposed to be, but often the errata prove otherwise
41 2012-08-27 00:18:51 <gmaxwell> genjix: Yep.
42 2012-08-27 00:19:12 <sipa> gmaxwell: any context?
43 2012-08-27 00:19:39 <sipa> kjj: not surprising, given the several layers of processing involved after machine language
44 2012-08-27 00:20:06 <genjix> kjj: tbh cpu differences are minor compared to platform differences for implementors.
45 2012-08-27 00:20:18 <genjix> maybe it mattered more in the time of gossplatt
46 2012-08-27 00:20:20 <gmaxwell> sipa: it was just from some discussion about surveillance and I was just making a wry comment that as a whole the public is massively opting into a level of surveillance which could never have been forced on them.
47 2012-08-27 00:20:23 <kjj> and since we hit the wall of jello just north of 3 GHz, compilers have become really strange
48 2012-08-27 00:20:58 <gmaxwell> kjj: :( Nothing is strange. Compilers that did these sorts of optmizations are really not new.
49 2012-08-27 00:21:41 <kjj> Yeah, optimization has been around forever
50 2012-08-27 00:21:49 <gmaxwell> If you can tell the difference between a correct optimizing compiler and a non-optimizing one; other than performance; then your code is wrong.
51 2012-08-27 00:21:55 <genjix> *greenplatt not gossplat
52 2012-08-27 00:22:49 <kjj> but modern CPUs spend a non-trivial amount of their lives doing work that they need to roll back, and modern compilers are built for THAT world now
53 2012-08-27 00:23:50 <kjj> the kernel-c thing is dead on, but all of us do it to some extent. we visualize ASM, and then assume a CPU that we can understand is executing that ASM. neither is true any more
54 2012-08-27 00:25:09 <gmaxwell> It wasn't true 20 years ago. It was somewhat true 30 years ago, so long as you used C and not fortran.
55 2012-08-27 00:25:30 <kjj> even debugging is odd now. we imagine the CPU screeching to a dead stop when it hits a breakpoint, but the truth is that it is travelling back in time a few hundred instructions
56 2012-08-27 00:25:54 <gmaxwell> kjj: the observable behavior is still identical.
57 2012-08-27 00:26:03 <genjix> i'm not a c-coder. i write c++ and deal with objects and abstractions.
58 2012-08-27 00:26:15 <genjix> we don't think imperically.
59 2012-08-27 00:26:25 <genjix> *imperatively
60 2012-08-27 00:26:27 <kjj> heh. the quantum physics argument applied to C code.
61 2012-08-27 00:26:44 <sipa> genjix: still C++ is a very imperative language :)
62 2012-08-27 00:27:02 <kjj> the photons leave here and are observed there. nothing else is real
63 2012-08-27 00:27:26 <sipa> genjix: but I see what you mean; you are abstracting from some details, indeed
64 2012-08-27 00:27:33 <genjix> yeah depends on the level. for methods and small pieces of code.
65 2012-08-27 00:28:11 <genjix> right. that's why template metaprogramming is great for algorithms, but not for the higher levels.
66 2012-08-27 00:28:38 <kjj> brb
67 2012-08-27 00:30:20 <genjix> https://www.youtube.com/watch?v=zh8W4ZglOlw
68 2012-08-27 00:34:43 <kjj> anyone know namecoin in detail? I had an idea for an altchain that would actually be useful, but I figured I'd better educate myself before inflicting it on the world
69 2012-08-27 01:02:52 <ne0futur> kjj: what kind of details ? try #namecoin anyway
70 2012-08-27 01:03:28 <ne0futur> gmaxwell: also if you find a better eample of a backdoor triggered by a compiler, i m interested
71 2012-08-27 01:03:45 <ne0futur> I just havent found better than http://www.grsecurity.net/~spender/exploits/exploit2.txt until now
72 2012-08-27 01:04:16 <gmaxwell> It's not 'triggered by a compiler' :( It's triggered by incorrect code that dereferences a null pointer.
73 2012-08-27 01:08:15 <ne0futur> find a better example
74 2012-08-27 01:08:43 <ne0futur> Also, bypass of mmap_min_addr via SELinux vulnerability!
75 2012-08-27 01:08:44 <ne0futur> large class of kernel vulnerabilities)
76 2012-08-27 01:10:24 <ne0futur> lets speak of multi level, well hidden backdoor
77 2012-08-27 01:16:51 <gmaxwell> also, It's _not_ a 'backdoor'. It's a rather boring bug. And mmap_min_addr on many systems without selinux (e.g. ubuntu) has historically been set to zero for compatiblity with wine.
78 2012-08-27 01:30:50 <ne0futur> thanks for the better example
79 2012-08-27 04:01:26 <devrandom> sipa: that is a benign warning
80 2012-08-27 05:01:43 <keverw> Hey guys! Does anyone know of a Node.js script that will console.log in real time the address that got paid, address that paid it, how much got paid only after 6 confirms. I have an idea for something that needs to be real time. Just need that basic thing. I seen JS libs where you can check an address balance and stuff but I would like something higher level. I'm a broke student but willing to pay for this if I had to.
81 2012-08-27 05:03:50 <kreal> read about json-rpc
82 2012-08-27 05:05:06 <kreal> I bet you can even make it yourself with enough reading :)
83 2012-08-27 05:05:16 <kreal> but if that fails I can help if you want.
84 2012-08-27 05:06:25 <kreal> Question, can I make symbolic links to the blockchain and dbs and have more bitcoin daemons refer to this?
85 2012-08-27 05:06:51 <kreal> or use -datadir to the same directory.
86 2012-08-27 05:06:59 <keverw> I figured I would have to build something that would get the recent trans with 6 confirms, send the tx data to my function that takes (toAddr, fromAddr, amount), and then mark that TXID as being used already in a MySQL database.. hmm
87 2012-08-27 05:07:16 <keverw> Like some sort of polling I guess. Does that seem like an idea or is there something better?
88 2012-08-27 05:08:24 <kreal> comet
89 2012-08-27 05:08:35 <kreal> http://en.wikipedia.org/wiki/Comet_%28programming%29
90 2012-08-27 05:08:45 <kreal> long pull http requests.
91 2012-08-27 05:09:01 <kreal> donno ?
92 2012-08-27 05:10:20 <keverw> I also know of http://blockchain.info/api/api_websocket but not sure if I should put my whole business on one API...
93 2012-08-27 05:11:04 <keverw> and I doubt that runs on test net. So doubt I could really test...
94 2012-08-27 08:35:06 <sipa> devrandom: still, it failed
95 2012-08-27 08:35:34 <sipa> in var/install.log i get an error about apt-get not being able to connect to 10.0.2.2
96 2012-08-27 10:48:46 <kakobrekla> are there any txes at the moment that will never be included in a block?
97 2012-08-27 11:20:21 <gmaxwell> kakobrekla: sure
98 2012-08-27 11:20:29 <kakobrekla> yes?
99 2012-08-27 11:20:38 <gmaxwell> kakobrekla: 4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2 for example
100 2012-08-27 11:21:09 <kakobrekla> whats wrong with this one
101 2012-08-27 11:21:28 <gmaxwell> There are also many double spends. E.g. coinbase was paying refferal bonuses with them a couple weeks ago. 0_o.
102 2012-08-27 11:21:34 <gmaxwell> It's an invalid P2SH spend.
103 2012-08-27 11:21:42 <copumpkin> was that just a bug in coinbase?
104 2012-08-27 11:21:48 <gmaxwell> copumpkin: I assume.
105 2012-08-27 11:21:51 <copumpkin> also, did they really call themselves coinbase? :(
106 2012-08-27 11:21:52 <copumpkin> boo
107 2012-08-27 11:22:39 <gmaxwell> copumpkin: no worse than 'blockchain'. Pretty crappy all these companies calling themselves components of bitcoin; creates a lot of confusion. At least coinbase is more obscure.
108 2012-08-27 11:22:47 <kakobrekla> so before tx gets 1 confirm, there there a way of seeing that it wont get included
109 2012-08-27 11:23:11 <gmaxwell> kakobrekla: yes, ... dont make it invalid in the first place?
110 2012-08-27 11:23:12 <copumpkin> well, blockchain.info has always used the .info as part of its name, but yeah it's kinda shitty too
111 2012-08-27 11:23:31 <gmaxwell> copumpkin: they might, but their users don't.
112 2012-08-27 11:23:38 <kakobrekla> whats wrong with blockchain.info?
113 2012-08-27 11:23:46 <copumpkin> oh I guess their logo doesn't either
114 2012-08-27 11:23:50 <copumpkin> so nevermind, it's shitty :)
115 2012-08-27 11:24:11 <gmaxwell> (in fact, it's not an unusual happening that people confuse the blockchain with 'blockchain.info' e.g. they think that blockchain.info is the centeral server of bitcoin)
116 2012-08-27 11:24:27 <gmaxwell> (Then again, I don't think I would have forseen that outcome either)
117 2012-08-27 11:25:12 <gmaxwell> kakobrekla: you can always check the blocktemplate call on a full node to see if its attempting to include it. If it is, any other full node with the same version would be too.
118 2012-08-27 11:25:52 <lianj> gmaxwell: it was a locking bug in the coin selection
119 2012-08-27 11:26:22 <kakobrekla> gmaxwell may i pm you
120 2012-08-27 11:27:12 <gmaxwell> kakobrekla: Sure.
121 2012-08-27 11:27:24 <gmaxwell> But if you ever ask me that in public again the answer will be no.
122 2012-08-27 11:27:27 <gmaxwell> :)
123 2012-08-27 11:40:25 <slush> hi
124 2012-08-27 11:40:55 <gmaxwell> HI
125 2012-08-27 11:41:46 <slush> Yesterday I was offline for some time, but I mined few blocks on testnet3. Today I connected my bitcoin to the network and I expected that it will resync with the network. If my blocks win, I'll see them on blockexplorer.com/testnet, otherwise I'll see my blocks as orphaned.
126 2012-08-27 11:42:23 <gmaxwell> Yes. I would expect that, although note that blockexplorer's handling of large reorgs is flaky.
127 2012-08-27 11:42:40 <slush> On startup my bitcoind displays my chain as valid, my peers have 21108 blocks, my height 21215 and nothing happen
128 2012-08-27 11:43:08 <slush> gmaxwell: it's not just about blockexplorer, I expected that my connected peers will start downloading my blocks
129 2012-08-27 11:43:20 <gmaxwell> slush: a new block is needed to trigger the reorg.
130 2012-08-27 11:43:41 <slush> oh
131 2012-08-27 11:44:09 <slush> so just the fact that other peer advertise different blockheight isn't enough?
132 2012-08-27 11:44:28 <gmaxwell> Those height advertisements are basically used for nothing; just display purposes.
133 2012-08-27 11:44:39 <slush> ok, that explains something
134 2012-08-27 11:45:27 <slush> so if some other peer push block from that shorter chain to me, my bitcoind will tell him that he has longer chain, right?
135 2012-08-27 11:48:35 <gmaxwell> IIRC, no. The only thing that will trigger it is you announcing a block.
136 2012-08-27 11:49:11 <slush> and how can I do that using current git version?
137 2012-08-27 11:50:06 <gmaxwell> The most obvious way would be to mine another block. It might be possible to resubmit using submitblock but I've not tried.
138 2012-08-27 11:50:54 <slush> Maybe I'm bitching, but this looks like a bug. There's already possibly longer chain in existence, but bitcoin don't announce it into the network.
139 2012-08-27 11:52:43 <gmaxwell> "Meh"
140 2012-08-27 11:53:07 <sipa> in normal operation, the active chain is always being worked on
141 2012-08-27 11:53:19 <sipa> it's a rather strange situation for a testnet
142 2012-08-27 11:53:25 <gmaxwell> hm. we don't seem to have a call to get the raw block, so I can't see if I can trigger a reannounce with submit block.
143 2012-08-27 11:53:52 <slush> sipa: how is this relevant to testnet? Shouldn't be bitcoin resistant against network split?
144 2012-08-27 11:54:09 <gmaxwell> slush: this behavior arguably increases resistance against network split.
145 2012-08-27 11:54:30 <gmaxwell> Because it means that the network won't reorg to a temporarily longer but dead fork.
146 2012-08-27 11:54:51 <slush> gmaxwell: yes, getrawblock() would be handy for this situation
147 2012-08-27 11:55:21 <slush> hm, it makes sense. but it looks weird at least at first view
148 2012-08-27 11:56:04 <gmaxwell> (It's not attack resistance, of course, because an attacker could just force the announcements.)
149 2012-08-27 11:57:00 <sipa> ACTION feels like refactoring main entirely
150 2012-08-27 11:57:40 <slush> ACTION is trying to mine new block at my netbook @1MHash/s, not so funny
151 2012-08-27 11:58:11 <gmaxwell> slush: hehe. well, diff 1 should only take it about an hour or so.
152 2012-08-27 11:58:12 <sipa> ACTION believes slush has enough hash power to assign, if he really needs to
153 2012-08-27 11:59:38 <TD> good afternoon
154 2012-08-27 11:59:46 <sipa> hi there
155 2012-08-27 11:59:57 <slush> not here. and redirecting pool to testnet isn't so good idea
156 2012-08-27 12:00:05 <sipa> slush: i was kidding :)
157 2012-08-27 12:00:09 <slush> :) i know
158 2012-08-27 12:00:52 <justmoon> TD: hey, leveldb native win32 api port compiles and works, but there is a rare semi-random data corruption issue I'm stuck on
159 2012-08-27 12:00:54 <gmaxwell> TD: so, wrt r decompression, what happens if a peer lies about the R value for a transaction? E.g. can I make an invalid signature look valid in the batch validation by providing the wrong y coorrid?
160 2012-08-27 12:01:01 <TD> justmoon: hrm
161 2012-08-27 12:01:06 <TD> justmoon: i'm rebasing that branch at the moment
162 2012-08-27 12:01:31 <TD> gmaxwell: i don't believe so. at least the paper claims not :) the first step of the ecdsa algorithm is basically finding R from r.
163 2012-08-27 12:01:39 <sipa> gmaxwell: i think checking whether R is on the curve is fast
164 2012-08-27 12:02:12 <gmaxwell> TD: sure sure, but if its someone _else_ that does the finding?
165 2012-08-27 12:02:16 <TD> the checking process solves using the value of s and then compares to R. if you can produce the correct R, it means you have the private key. i think.
166 2012-08-27 12:02:31 <TD> yes, that's what i mean
167 2012-08-27 12:02:37 <TD> it's equivalent
168 2012-08-27 12:02:51 <TD> you can't find an R that will let you forge a signature
169 2012-08-27 12:03:00 <sipa> but if someone sends a Ctransaction2
170 2012-08-27 12:03:13 <sipa> and some peers modifies the y coordinate in transit
171 2012-08-27 12:03:25 <TD> i think it just breaks the signature then
172 2012-08-27 12:03:36 <sipa> well yes, but that will make you think the transaction is invalid
173 2012-08-27 12:03:42 <gmaxwell> Yea, but thats a kind of DOS you can guard against.
174 2012-08-27 12:04:01 <TD> sipa: yes. but you can modify the signatures in transit already
175 2012-08-27 12:04:08 <gmaxwell> if a Ctransaction2 fails you do it the slow way, and if it still fails only then do you remember the result.
176 2012-08-27 12:04:08 <TD> i don't see how it's any different?
177 2012-08-27 12:04:19 <sipa> TD: you can't make them invalid without changing the txid
178 2012-08-27 12:04:33 <TD> SignatureHash does not include the signatures themselves, obviously, so modifying the signature does not change the txid
179 2012-08-27 12:04:49 <sipa> SignatureHash != TransactionHash
180 2012-08-27 12:05:04 <TD> oh, right
181 2012-08-27 12:05:05 <TD> duh
182 2012-08-27 12:05:09 <sipa> and certainly changing the signature changes the txid
183 2012-08-27 12:05:22 <TD> sure, but then so what? what does this let you do?
184 2012-08-27 12:05:38 <gmaxwell> td: kill txn on the network, unless it's guarded against.
185 2012-08-27 12:05:59 <gmaxwell> I get a txn from you, I make an invalid version, announce it everywhere. No one will take your valid version.
186 2012-08-27 12:06:16 <sipa> my question is: can you still do batch verification if you do R-reconstruction at verification time in advance?
187 2012-08-27 12:06:23 <sipa> *with speedup
188 2012-08-27 12:06:40 <TD> gmaxwell: you have to calculate "r" during signature checking anyway, so at that point it's trivial to make sure the legacy value matches
189 2012-08-27 12:07:32 <gmaxwell> TD: er. but you don't expect it to match for an invalid signature.
190 2012-08-27 12:07:44 <sipa> r is part of the signature, not calculated during verification afaik?
191 2012-08-27 12:08:11 <sipa> oh, never mind
192 2012-08-27 12:08:51 <TD> gmaxwell: if they don't match you drop the tx. the correct version is still accepted by the network. i guess the DoS blacklists would use a hash of CTx2 or something
193 2012-08-27 12:09:07 <gmaxwell> The question is "is this invalid because it's really invalid, or because we got bad acceleration data" In the latter case you just ban the peer and reinject the txn with fixed acceleration data. In the former case you remember than the txn is bad so you don't request it again.
194 2012-08-27 12:09:12 <gmaxwell> TD: or that.
195 2012-08-27 12:09:25 <gmaxwell> yes, if ctx2 peers used the ctx2 id instead of the txid that would work.
196 2012-08-27 12:09:52 <TD> sipa: in ecdsa* it's calculated. i'm not sure why the papers are based on ecdsa* instead of regular ecdsa
197 2012-08-27 12:10:23 <sipa> R is calculated in regular ECDSA as well, and its x component is compared to the submitted r value
198 2012-08-27 12:10:27 <gmaxwell> In any case, sorry for the rathole. :) This is all only important once someone has actual code that gets the Nx speedup. :)
199 2012-08-27 12:10:31 <TD> sipa: you're right - given that you can convert between R and r with some work (apparently), I don't see why you need to modify the signatures. in fact there's a paper that deals with batch unmodified ECDSA
200 2012-08-27 12:10:38 <TD> but it reports less speedup. perhaps that's why
201 2012-08-27 12:10:54 <sipa> probably, the reconstruction part cannot be batched
202 2012-08-27 12:11:23 <TD> http://cse.iitkgp.ac.in/~abhij/publications/AfricaCrypt12-ECDSA-bv.pdf
203 2012-08-27 12:11:29 <TD> that's batching for unmodified ECDSA
204 2012-08-27 12:11:41 <TD> "Experiments carried out on NIST prime curves demonstrate a maximum speedup
205 2012-08-27 12:11:42 <TD> batch belong to different signers"
206 2012-08-27 12:12:11 <TD> vs 4x for ECDSA*
207 2012-08-27 12:12:15 <TD> in the multi-signer case
208 2012-08-27 12:12:23 <TD> so apparently it's a big difference. that must be why they modified the signatures.
209 2012-08-27 12:18:11 <TD> also the ecdsa* is a lot faster for non-koblitz curves
210 2012-08-27 12:22:09 <gmaxwell> Gitk visualization of the bitcoin git repo looks like an LA freeway map: https://people.xiph.org/~greg/ss-gitk.png
211 2012-08-27 12:22:32 <TD> LA must have some pretty dangerous freeways
212 2012-08-27 12:54:05 <gavinandresen> Looking for review/ACK's for the DoS fix that I've been working on: https://github.com/bitcoin/bitcoin/pull/1729
213 2012-08-27 13:08:17 <BlueMatt> sipa: re: gitian, no, but I have an equivalent environment...anyway, Id have to suggest sticking with pull-testers build (Im assuming its way too late anyway)
214 2012-08-27 13:14:14 <gavinandresen> BlueMatt: can you summarize the paths to getting a gitian-built 0.7 ?
215 2012-08-27 13:18:50 <BlueMatt> I believe luke was working with devrandom to get it working in lxc, so in theory, you can do a gitian build in an ubuntu vm, otherwise I believe you still need vt-x hardware running ubuntu (or, just get the actual ubuntu base vm using the make-base-vm script in a physical ubuntu, then use that on any kvm system, which is what I do)
216 2012-08-27 13:19:03 <BlueMatt> I dont know much about the status of the lxc stuff, you'd have to ask luke
217 2012-08-27 13:19:34 <BlueMatt> in terms of build right now, need to upgrade to boost 1.50 and merge one of luke's commits before it will build
218 2012-08-27 13:19:35 <gavinandresen> BlueMatt: I meant a summary of the "pull 1716 versus upgrade to Boost 1.50"
219 2012-08-27 13:20:15 <gavinandresen> gitian building doesn't work right now? Or URI support won't work without upgrading...
220 2012-08-27 13:20:23 <BlueMatt> no, it fails
221 2012-08-27 13:20:31 <BlueMatt> pull 1716 moves the boost monkey-patch to the header before including boost, which would work, but its as ugly (or I'd argue uglier) than the orginal patch
222 2012-08-27 13:20:55 <gavinandresen> what made it start failing?
223 2012-08-27 13:21:04 <BlueMatt> I believe me
224 2012-08-27 13:21:18 <BlueMatt> the upgrade to boost 1.49 killed it, but also my patch (apparently)
225 2012-08-27 13:21:58 <BlueMatt> Id like to see us just upgrade to 1.50 to fix the issue (aside from the typo in 1.49)
226 2012-08-27 13:22:24 <gavinandresen> ok... backing out whatever made things break seems like it would be the safest, but I agree that moving forward is better than back.
227 2012-08-27 13:22:39 <BlueMatt> but, apparently, to get it to build as a part of gentoo's stuff, we'd still need the patch
228 2012-08-27 13:22:53 <BlueMatt> Im torn as to whether or not we should keep it, or make gentoo put it in their patch list
229 2012-08-27 13:23:18 <gavinandresen> what's market share of gentoo?
230 2012-08-27 13:23:42 <BlueMatt> its not just gentoo, its gentoo compiling for win32, so...none?
231 2012-08-27 13:25:18 <BlueMatt> we still have the full rc phase, so I just figure any bugs boost 1.50 will introduce will get found (they are usually quite obvious) and we can revert if we have to
232 2012-08-27 13:25:41 <gavinandresen> ok, so what needs to get done to upgrade to 1.50. And is 1.50 the latest?
233 2012-08-27 13:26:01 <BlueMatt> 1.51 is, but it introduces bugs, I forget which, but laanjw linked it in the pull
234 2012-08-27 13:26:02 <gavinandresen> why not 1.51?
235 2012-08-27 13:26:24 <BlueMatt> #1719
236 2012-08-27 13:26:58 <gavinandresen> mmm... another 'causes issues on a platform we don't care about' issue....
237 2012-08-27 13:27:03 <BlueMatt> I figure upgrading to a fixed version of boost would be better than fixing it ourselves (as it is now, as I did it to fix...whatever it was)
238 2012-08-27 13:27:20 <gavinandresen> (yeah, yeah, I know Wine is useful for wumpus to test stuff)
239 2012-08-27 13:27:42 <BlueMatt> well, itl kill pull-tester
240 2012-08-27 13:27:51 <gavinandresen> pull-tester uses Wine?
241 2012-08-27 13:27:55 <BlueMatt> yea
242 2012-08-27 13:27:59 <gavinandresen> sigh. OK
243 2012-08-27 13:28:08 <BlueMatt> (to run the test cases compiled for win32)
244 2012-08-27 13:28:58 <gavinandresen> All this mess is triggered by the URI boost:interprocess code, yes?
245 2012-08-27 13:29:15 <BlueMatt> dunno 'bout 1719, but the monkey-patch, yes
246 2012-08-27 13:29:32 <gavinandresen> 1719 is boost::interprocess
247 2012-08-27 13:29:39 <BlueMatt> must be then
248 2012-08-27 13:29:45 <sipa> what about a DISABLE_FANCY_WIN32_PROTECTION_STUFF in the makefiles that disables that stack protection, and using that in the build tester?
249 2012-08-27 13:30:12 <gavinandresen> what does stack protection have to do with any of this?
250 2012-08-27 13:30:17 <BlueMatt> wfm, though I do prefer to keep it as close as possible to the gitian ouptuts
251 2012-08-27 13:30:41 <BlueMatt> I dont think sipa is on the same topic
252 2012-08-27 13:30:49 <BlueMatt> (or is 1719 stack-protector related?)
253 2012-08-27 13:31:25 <gavinandresen> 1719 looks like a purely boost::interprocess issue, ticking a "wine doesn't support the right kind of semaphores" issue
254 2012-08-27 13:33:01 <sipa> BlueMatt: sorry, i just read something about wine compatibility, which that stack protection stuff broke, iirc?
255 2012-08-27 13:33:08 <sipa> but apparently you're talking about something else
256 2012-08-27 13:33:22 <BlueMatt> sipa: yes, adding -fstack-protector kills wine
257 2012-08-27 13:33:37 <BlueMatt> but we're on the gitian booost 1.50/monkey-patch stuff atm
258 2012-08-27 13:33:45 <BlueMatt> (#1716)
259 2012-08-27 13:34:40 <gavinandresen> Ok: seems like the right thing to do is: pull 1716. Monkey-patch or #define before #include are equally ugly in my humble opinion.
260 2012-08-27 13:35:04 <BlueMatt> agreed, but can we please also do 1.50 before we start rc?
261 2012-08-27 13:35:16 <gavinandresen> what needs to be done to "do 1.50" ?
262 2012-08-27 13:35:37 <BlueMatt> s/49/50/ and bump boost-gitian yml version
263 2012-08-27 13:35:51 <gavinandresen> s/49/50/ where ?
264 2012-08-27 13:36:03 <BlueMatt> makefiles and gitian files should be it afaik
265 2012-08-27 13:36:13 <BlueMatt> just the mingw/linux-mingw and qt .pro ones i believe
266 2012-08-27 13:36:27 <TD> how does it kill wine, btw?
267 2012-08-27 13:36:36 <TD> i may be able to fix that. i spent a few years as a codeweavers employee
268 2012-08-27 13:36:46 <TD> so i know the wine codebase better than any healthy person should
269 2012-08-27 13:36:49 <BlueMatt> TD: https://github.com/bitcoin/bitcoin/pull/1674
270 2012-08-27 13:37:03 <gavinandresen> TD: that's the type of thing I would keep a deep, dark secret
271 2012-08-27 13:37:05 <BlueMatt> may want to talk to gmaxwell/Diapolo
272 2012-08-27 13:38:30 <gavinandresen> BlueMatt: if you want boost 1.50, create a pull request that does the right things....
273 2012-08-27 13:38:39 <TD> thanks
274 2012-08-27 13:38:54 <BlueMatt> gavinandresen: ack, give me a few hours
275 2012-08-27 13:39:33 <TD> gavinandresen: it gets worse. my job was to reimplement DCOM
276 2012-08-27 13:39:44 <gavinandresen> TD: oh my.
277 2012-08-27 13:39:50 <BlueMatt> ouch...
278 2012-08-27 13:40:17 <gavinandresen> TD: you must have all sorts of nasty technical details filling up valuable brainspace
279 2012-08-27 13:41:09 <TD> the sort of thing that will come out in therapy one day. i'll just blurt out CoMarshalInterThreadInterfaceInStream(pUNK) and end up being committed
280 2012-08-27 13:41:24 <gavinandresen> BlueMatt: besides warm fuzzies, do we gain anything by switching from boost 1.49 to boost 1.50 ?
281 2012-08-27 13:41:39 <TD> gavinandresen: why make the string part of the alert protocol? that just means it can't be internationalized
282 2012-08-27 13:42:04 <gavinandresen> TD: because otherwise an attacker with the key could send out a blank message which couldn't be overridden.
283 2012-08-27 13:42:14 <BlueMatt> gavinandresen: nope, just warm fuzzies and less chance of something 'splodin later because we forgot to throw in the patch before #including <boost/foreach.hpp> which for some godawful reason includes <boost/interprocess/*>
284 2012-08-27 13:42:30 <sipa> wait, what?
285 2012-08-27 13:42:31 <TD> i mean, in the maxID case, just ignore the message entirely and then substitute in a hard-coded one at the gui level
286 2012-08-27 13:42:46 <TD> BlueMatt: boost foreach macro includes IPC code, what?!
287 2012-08-27 13:42:56 <gavinandresen> TD: sure, that could be done...
288 2012-08-27 13:42:57 <BlueMatt> TD: no, its an example
289 2012-08-27 13:43:00 <TD> oh
290 2012-08-27 13:43:02 <TD> phew
291 2012-08-27 13:43:05 <BlueMatt> yea
292 2012-08-27 13:43:09 <BlueMatt> that would be "godawful"
293 2012-08-27 13:44:04 <gavinandresen> TD: hard-coded string appears in RPC output, too, which doesn't go through the i18n stuff
294 2012-08-27 13:44:11 <sipa> TD: I hoped they paid you to compensate for psychological and probably physical damages resulting from that?
295 2012-08-27 13:44:17 <TD> i was paid, yes
296 2012-08-27 13:44:27 <TD> not much but for a student it didn't seem so bad
297 2012-08-27 13:53:00 <BlueMatt> wait...we dont already assign a DoS value to alerts with invalid sigs...
298 2012-08-27 13:54:18 <gavinandresen> nope, we don't.
299 2012-08-27 13:54:35 <gavinandresen> jgarzik: I thought you were at a nice beach somewhere.
300 2012-08-27 13:54:39 <BlueMatt> well, good thing someone's fixing that...
301 2012-08-27 13:55:17 <jgarzik> gavinandresen: I am! :)
302 2012-08-27 13:55:33 <jgarzik> the only way I could do a whole week at the beach was to work Monday & Tuesday :)
303 2012-08-27 13:55:53 <jgarzik> ACTION turns left, and looks at the Atlantic Ocean from his beach condo
304 2012-08-27 13:56:02 <gavinandresen> ACTION is jealous
305 2012-08-27 13:56:04 <TD> nice!
306 2012-08-27 13:56:08 <BlueMatt> nice
307 2012-08-27 13:56:08 <jgarzik> great place for coding NFSv4.1 services
308 2012-08-27 13:56:21 <jgarzik> possibly more complex than a bitcoin-validating python node
309 2012-08-27 13:57:02 <BlueMatt> well, get off bitcoin and finish up to look at the beach more ;)
310 2012-08-27 13:58:02 <TD> BlueMatt: is your dns seed coming back at any point?
311 2012-08-27 13:58:07 <BlueMatt> its up
312 2012-08-27 13:58:10 <BlueMatt> is it now?
313 2012-08-27 13:58:31 <TD> dnsseed.bluematt.me ?
314 2012-08-27 13:58:32 <BlueMatt> no, looks up to me
315 2012-08-27 13:58:33 <BlueMatt> yea
316 2012-08-27 13:58:48 <TD> odd
317 2012-08-27 13:58:54 <TD> i'm seeing (from bitcoinj): 05:58:07 11 DnsDiscovery.getPeers: DNS lookup for dnsseed.bluematt.me failed.
318 2012-08-27 13:58:59 <TD> also when I do a dig on it, I get no A records
319 2012-08-27 13:59:07 <sipa> looks up from here