< cfields>
achow101: any chance you could grab the .o files from your gitian environment?
< gmaxwell>
sipa: re random, seeding is a lot more of an interesting issue... that patch feels like sideways motion to me. sounds fine and all but doesn't obviously get rid of openssl.
< sipa>
gmaxwell: sure... 1) make fastrandomcontext stronger 2) move some uses that now use getrandbytes to fastrandomcontexts 3) move everything else to a single secure RNG 4) make that single secure RNG not be OpenSSL
< sipa>
when every use of the strong RNG reads from /dev/urandom etc, i feel we can avoid a lot of the complexity in it (gathering entropy etc)
< sipa>
s/gathering/background/
< achow101>
cfields: I don't think so
< cfields>
achow101: ok
< gmaxwell>
Making fastrandomcontext robust agaist VM restore, forward/backward prediction will make it slow.
< sipa>
gmaxwell: don't use fastrandomcontext in places where it needs to be robust
< sipa>
we don't need VM robustness for determining the filename we temporarily write the addrman db to
< sipa>
(which currently uses GetRandBytes)
< gmaxwell>
We don't, I agree. But review what you just said above!
< sipa>
2) move *some* uses that now use getrandbytes to fastrandomcontexts
< gmaxwell>
okay I looked through the usage of GetRand* and I'm less skeptical.
< gmaxwell>
The ones where we need better properties we can use something fantastically slow.
< sipa>
right, anything that constructs an actual secret key usually just runs once during the whole application (cache blinding keys, wallet keys, ...)
< sipa>
for ping nonces i don't think that VM restores are that much of a deal
< cfields>
sigh, best i can tell the linker is reordering some symbols
< cfields>
don't know how we could be running into that now and not before, though
< achow101>
it would be great if someone else could also do a gitian build :/
< cfields>
yea :(
< cfields>
I'm going to have to throw in the towel for tonight. I'll pick it up again tomorrow. Will be much easier with a third data point.
< achow101>
nuked cache and input (except for sdk). trying again
< cfields>
achow101: double-check your sdk? The only thing I can come up with other than ld64 constructing the indirect symbol table in a non-deterministic order, is that your sdk has a different stub which leads to a different layout
< luke-jr>
my guess would be something with his VM
< cfields>
luke-jr: thanks, btw
< luke-jr>
np, sorry I'm late
< cfields>
luke-jr: i'm not sure what could matter, other than filesystem or locale
< achow101>
how do I check the sdk? I don't really have a way to get another one
< cfields>
but i'd think those would cause many issues, not just these
< achow101>
(short of someone sending me one)
< cfields>
achow101: the dump you gave me matches mine. Just make sure that's really the one you're using
< cfields>
achow101: lxc or kvm?
< achow101>
kvm
< cfields>
ok
< * luke-jr>
is also KVM
< cfields>
yes, same
< achow101>
lxc stopped working for me a long time ago. I still have an issue open somewhere about it
< achow101>
the sdk is definitely the same. my original and the one in inputs have the same sha256sum
< wumpus>
apparently my for gitian output for linux mismatches
< wumpus>
windows matches, and osx too (except for achow101)
< wumpus>
linux: looks like only the x86_64 output mismatches - aarch64, arm, i686 are the same
< wumpus>
cfields: your gitian assert package overview has "Reading package lists..." ""Building dependency tree..." apt command output in it
< wumpus>
my assert has *three* versions of g++-4.8 in it:g++-4.8_4.8.2-19ubuntu1_amd64.deb, g++-4.8_4.8.4-2ubuntu1~14.04.1_amd64.deb, g++-4.8_4.8.4-2ubuntu1~14.04.3_amd64.deb ... that seems overkill
< wumpus>
that almost must be the problem, will try to clean it up
< wumpus>
the base image that is, not the assert file :)
< achow101>
I'm going to be away from my build computer today so I won't be able to help
< cfields>
ok
< cfields>
i guess if we have 3 matches we can go with that one, but we really need to figure out why we're getting 2 different results
< achow101>
I tried remaking the base vm and rebuilding before I left but I was having issues with making it
< cfields>
achow101: thanks for trying
< cfields>
wumpus: please confirm if you'd like me to go ahead and push the sigs for the one we've got. the fact that achow101 and fanquake have matching mismatches for osx is a bit worrisome
< MarcoFalke>
"matching mismatches", heh.
< MarcoFalke>
going to run the osx gitian, lets see what my result is...
< cfields>
ok, i'm going to go ahead and push
< cfields>
we need to try to figure out what the discrepancy is before rc2, though
< cfields>
gitian builders: detached osx/win sigs for 0.14.0rc1 pushed.
< cfields>
achow101 / fanquake: not sure what to tell you yet, i'll keep trying to get it pinned down
< wumpus>
cfields: yes, let's try to continue. It's strange that macosx apparently isn't determinstic, but that's no reason to not go on with the other platforms for rc1
< wumpus>
would be nice to sort this out before final, of course
< luke-jr>
[13:09:35] <wumpus> ok, above gitian issue was solved by rebuildling with a new base image <-- eh, not sure this is a good resolution :|