1 2016-08-01 13:05:12 <rafalcpp> hmm I builded bitcoin using gitian (v 0.12.0) and the resulting bitcoin tgz in fact differs compared to what other asserted... wumpus
  2 2016-08-01 13:06:08 <rafalcpp> all binaries inside do differ, e.g.:
  3 2016-08-01 13:06:24 <rafalcpp> bitcoin-0.12.0-downloaded/bin/bitcoind: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=3e44ab72fc71e510209554ae5d2e4674812c97f1, stripped
  4 2016-08-01 13:06:25 <rafalcpp> bitcoin-0.12.0-mylxc/bin/bitcoind:      ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=a69a81a08bc338f5f0fa183b04cf17aade34cc25, stripped
  5 2016-08-01 13:08:55 <rafalcpp> the bitcoin is in version v0.12.0, git log -1 in ~/gitian-builder/inputs/bitcoin is 188ca9c3, so is tag v0.12.0
  6 2016-08-01 13:48:21 <rafalcpp> the difference is largely related to address of gmtime_r@plt+...
  7 2016-08-01 13:49:12 <rafalcpp> comparing asm (objdump -d) between my gitian build and binary from bitcoin.org
  8 2016-08-01 13:49:23 <rafalcpp> -   6d98f:  e8 cc 59 4f 00        callq  563360 <gmtime_r@plt+0x5008c0>
  9 2016-08-01 13:49:24 <rafalcpp> -   6d994:  48 8d 3d 95 62 4f 00  lea    0x4f6295(%rip),%rdi        # 563c30 <gmtime_r@plt+0x501190>
 10 2016-08-01 13:49:26 <rafalcpp> +   6d98f:  e8 6c 0c 52 00        callq  58e600 <gmtime_r@plt+0x52bb60>
 11 2016-08-01 13:49:27 <rafalcpp> +   6d994:  48 8d 3d 35 15 52 00  lea    0x521535(%rip),%rdi        # 58eed0 <gmtime_r@plt+0x52c430>
 12 2016-08-01 14:00:09 <rafalcpp> maybe the library providing gmtime_r has now gmtime_r() at othe addresses, meaning that it's ABI changed
 13 2016-08-01 14:02:50 <wumpus> yes now you say I remember there were some changes to gcc during the release cycle for a recent release, I think that was for either 0.12.0 or 0.12.1
 14 2016-08-01 14:04:10 <wumpus> for a certain rcX we couldn't get the results to match, turned out part of the people built with one gcc package and one part with another, was bad timing from the ubuntu side
 15 2016-08-01 14:05:04 <rafalcpp> wumpus: changes to gcc, or to libc?
 16 2016-08-01 14:05:22 <wumpus> in our case it was gcc
 17 2016-08-01 14:05:40 <rafalcpp> but that was other problem, or this one?
 18 2016-08-01 14:05:50 <rafalcpp> was it also causing other addresses of funcdtions like gmtime_r?
 19 2016-08-01 14:05:56 <wumpus> it was a similar problem where small parts of the code were moved to other places
 20 2016-08-01 14:06:10 <wumpus> and optimized differently
 21 2016-08-01 14:06:16 <wumpus> I don't remember anything about a specific function
 22 2016-08-01 14:06:17 <rafalcpp> well that is another issue, that other gcc version compiles in other way... yeah or optimize
 23 2016-08-01 14:06:35 <rafalcpp> but what about this library version thing, it seems more obvious
 24 2016-08-01 14:06:53 <rafalcpp> I think each time any used library changes, it will be not possible to reproduce. no one else reported this yet?
 25 2016-08-01 14:07:17 <wumpus> well libc is one of the only libraries not built from source
 26 2016-08-01 14:07:28 <wumpus> in any case, yes that can happen
 27 2016-08-01 14:07:48 <wumpus> if you really want to reproduce an old build you'd have to somehow restore the packages mentioned in the assert
 28 2016-08-01 14:07:53 <rafalcpp> so maybe gitian build process should force specific version of libc (for function addresses), and of compiler (to avoid different optimizations)?
 29 2016-08-01 14:08:18 <wumpus> as of now gitian works well enough for building releases with N people where the output is the same, being able to build old releases would be nice, but is not the primary goal
 30 2016-08-01 14:08:19 <rafalcpp> (btw, good job ubuntu changing ABIs and compiler version in midle of stable release system ;)
 31 2016-08-01 14:09:00 <rafalcpp> wumpus: which version should now build the same for everyone as of today, the 0.12.1 of course?
 32 2016-08-01 14:09:10 <wumpus> 0.13.0rcX  at least
 33 2016-08-01 14:09:13 <rafalcpp> ok
 34 2016-08-01 14:09:44 <wumpus> well *for a certain release* you may want to fix a certain libc/gcc version
 35 2016-08-01 14:09:47 <rafalcpp> wumpus: patch to have gitian builder force libc, gcc (and maybe other) lib versions would be probably accepted?
 36 2016-08-01 14:09:58 <wumpus> this is what effectively happens by writing the package versions into the assert
 37 2016-08-01 14:10:17 <wumpus> if you later on build with different packages than in the assert, the release may be different
 38 2016-08-01 14:11:17 <wumpus> the problem with using a fixed release of anything is that you also miss security updated, or have to explicitly check them, that gives more work. We already have to do this for all packages in depends
 39 2016-08-01 14:12:16 <wumpus> e.g. there was a libc change at some point because DNS lookup was vulnerable
 40 2016-08-01 14:13:31 <wumpus> to be honest the ubuntu thing is a hack - I think the next step for gitian is to use a deterministic OS as well
 41 2016-08-01 14:14:04 <wumpus> or at least a toolchain that can be entirely deterministically built
 42 2016-08-01 14:14:06 <wumpus> debian is working on this
 43 2016-08-01 14:14:12 <wumpus> but I'm not sure how far they are
 44 2016-08-01 14:14:52 <wumpus> e.g. if you can build all the packages which were used to build a certain bitcoin release, you can always reproduce old builds
 45 2016-08-01 14:16:35 <wumpus> but it's good that someone shows interest in this, I think it's best to discuss this with cfields if you want to make improvements here
 46 2016-08-01 14:21:43 <rafalcpp> wumpus: but if you want to assert an old build, you want to in fact assert it as-it-was, including the old library including the library's bug
 47 2016-08-01 14:22:09 <wumpus> yes,I understand - for old releases you'd ideally want to be able to rebuild the old OS state
 48 2016-08-01 14:22:17 <rafalcpp> that's only way to make sure if you "turst no one" :) you're then checking historical honesty of other builders, not making a version to use
 49 2016-08-01 14:22:22 <rafalcpp> yea
 50 2016-08-01 14:23:16 <rafalcpp> wumpus: why bitcoin is build on Ubuntu btw, wouldn't Debian be better choice as it changes less often?
 51 2016-08-01 14:23:21 <wumpus> I think that's possible if historical packages are still available somewhere
 52 2016-08-01 14:23:52 <wumpus> rafalcpp: historical reasons
 53 2016-08-01 14:23:57 <helo> how does one verify that the OS state is indeed identical?
 54 2016-08-01 14:24:14 <wumpus> "packages built on ubuntu tend to work on many linux distros"
 55 2016-08-01 14:24:27 <wumpus> helo: the assert lists all of the installed package versions
 56 2016-08-01 14:24:45 <rafalcpp> helo: you can tell apt-get to get packages in given version
 57 2016-08-01 14:24:52 <wumpus> helo: including sha256sums IIRC - so if you can go back to exactly having those packages installed, the state should be the same
 58 2016-08-01 14:25:02 <helo> ah, nice
 59 2016-08-01 14:25:54 <wumpus> e.g. see under "trusty-amd64" https://github.com/bitcoin-core/gitian.sigs/blob/master/0.13.0rc2-linux/laanwj/bitcoin-linux-0.13-build.assert
 60 2016-08-01 14:25:58 <rafalcpp> are we also checksumming all downloaded .debs, or *only* checking if they are signed by distro?  (the later would allow a bit elaborated ploy to send troyaned, but signed, debs to some people)
 61 2016-08-01 14:26:54 <wumpus> they're checksummed, but there is nothing to check those checksums against
 62 2016-08-01 14:27:03 <rafalcpp> ah stupid question, yes we do - e8d54ec2e6fd538d231f90986ef7b76761644b8bab23e068c90950899b520f02 libc-bin_2.19-0ubuntu6.7_amd64.deb
 63 2016-08-01 14:27:03 <wumpus> it's just for reporting
 64 2016-08-01 14:28:02 <rafalcpp> wumpus: we could in gitian file write the expected checksums
 65 2016-08-01 14:28:07 <wumpus> the gitian builder installs and upgrades an ubuntu image, if ubuntu is compromised they could inject a fake gcc/g++ compiler that buildsi n a backdoor
 66 2016-08-01 14:28:21 <wumpus> and then? how would you actually verify those packages?
 67 2016-08-01 14:29:08 <rafalcpp> you could tell apt-get what is the expected checksum, if this isn't yet an option then you could wget yourself, checksum, and then dpkg -i
 68 2016-08-01 14:29:11 <wumpus> at the least they're reported, so deviations can be detected, but I don't think anything more is possible unless someone were to audit all the packages
 69 2016-08-01 14:29:46 <wumpus> yea.. how to get that 'expected checksum'? how to know what package is clean?
 70 2016-08-01 14:30:02 <wumpus> as said, going to a fully deterministically built OS may help, and is a future plan
 71 2016-08-01 14:30:05 <rafalcpp> wumpus: eventually entire debial also should become deterministic buildable
 72 2016-08-01 14:30:14 <wumpus> but without that, this would not add any actual security
 73 2016-08-01 14:30:24 <wumpus> we try to avoid security theater with the limited resources we have :)
 74 2016-08-01 14:30:38 <rafalcpp> https://wiki.debian.org/ReproducibleBuilds has a nice progress graph
 75 2016-08-01 14:31:06 <rafalcpp> wumpus: ok. I guess the option to rebuild historical builds by forcing version is all improvement that could make sense now.
 76 2016-08-01 14:31:16 <wumpus> yes
 77 2016-08-01 14:35:02 <wumpus> another thing that has been discussed is to reduce the size of the building base OS - ubuntu has a lot of overhead, packages that are unncecessary for building
 78 2016-08-01 14:35:19 <wumpus> starting with a debian minimal install would likely help there
 79 2016-08-01 14:36:24 <wumpus> if the base OS is small, one could simply archive the packages used to build each release, making it easier to find them for rebuilding
 80 2016-08-01 14:37:09 <rafalcpp> is there something in Ubuntu that is needed, or could it as well be debian now?
 81 2016-08-01 14:38:13 <wumpus> no, could switch to another OS for 0.14
 82 2016-08-01 14:38:19 <pigeons> and debian does have deterministic package building, i beleive based on bitcoin's gitian work (i think they credited tor though)
 83 2016-08-01 14:38:52 <wumpus> gitian can in principle handle debian already IIRC
 84 2016-08-01 14:39:21 <pigeons> not much info but https://wiki.debian.org/ReproducibleBuilds and for kernel https://wiki.debian.org/SameKernel
 85 2016-08-01 14:39:21 <wumpus> pigeons: yes, see the link rafalcpp gives a few lines back :)
 86 2016-08-01 14:39:27 <rafalcpp> :}
 87 2016-08-01 14:39:30 <pigeons> lol oops sorry ok
 88 2016-08-01 14:40:12 <pigeons> i started reading at "another thing". getting more coffee now :)
 89 2016-08-01 17:28:08 <`mist> hiya, if a wallet is not encrypted. Will it return a value for "locked"?
 90 2016-08-01 17:28:39 <`mist> and what i mean by that is if i run getinfo() on a unencrypted wallet, will the output be differnt from a getinfo() from an encrypted one?
 91 2016-08-01 17:34:25 <arubi> `mist, a locked wallet has a "unlocked_until" value returned from getinfo rpc.  not sure if that's the getinfo() you mean
 92 2016-08-01 17:36:01 <`mist> yeah but that only tells me if its locked or unlocked. Not if its encrypted or not
 93 2016-08-01 17:36:42 <arubi> well, s/locked/encrypted
 94 2016-08-01 17:37:23 <`mist> ok so an encrypted wallet will always have a unlocked_until value
 95 2016-08-01 17:37:35 <`mist> whether it the value is 10000 or 0. Its encrypted
 96 2016-08-01 17:37:45 <`mist> but if its not encrypted, it won't have this value at all?
 97 2016-08-01 17:37:48 <arubi> if it's 0, it's locked
 98 2016-08-01 17:37:57 <arubi> if it's more, then that's how many seconds until it locks
 99 2016-08-01 17:38:07 <`mist> and if it not encrypted at all?
100 2016-08-01 17:38:14 <arubi> if it's not encrypted, it doesn't return a locked_until value at all, right
101 2016-08-01 17:38:23 <`mist> sweet, perfect
102 2016-08-01 17:38:24 <`mist> thanks =)
103 2016-08-01 17:38:33 <arubi> cheers