Re: Security Implications of (Non)Reproducible Middleware Bu
Posted: Sun Sep 27, 2015 9:54 am
Anything that's relevant to Bitcoin Core would be submitted upstream. We're actually pretty militant about avoiding merging anything to Namecoin Core that is better done upstream, for exactly that reason. (The lack of that policy in the past contributed to us having to rewrite NamecoinQ into Namecoin Core.)  I'm mainly talking about changing strings in the documentation that are different between Bitcoin Core and Namecoin Core (e.g. the word "bitcoin" in some paths in the instructions).somename wrote:I think it would be better to submit improvements upstream (to Bitcoin Core), then the easier part (adjusting steps for Namecoin Core) could be documented by a Namecoin non-dev (or dev).
 Actually, some Namecoin developers *might* be okay with merging something like Zerocash without waiting for Bitcoin Core developers, because the way it affects us is quite different from Bitcoin's case. However, this is definitely not a given yet. I personally don't want to make policy exceptions for Zerocash given the current situation; things might change in the future.
The bigger problem is building Python reproducibly on Windows. (I'm not sure about OS X.) Mike and Seth's talk discussed a number of reasons why building reproducibly for Windows is important even though Windows itself doesn't build reproducibly. For example, if our builds for Windows are reproducible, that means there's no incentive to compromise our build process for the purpose of attacking some of our Windows users. It is plausible that Microsoft's build process is sufficiently secure that attacking non-reproducible cryptocurrencies is more effective than attacking Windows directly; we can avoid that by having reproducible Windows builds. (I'm not attempting to thoroughly enumerate the advantages of this; Mike and Seth do a much better job than I could.)somename wrote:Python: I think I pasted links to bugs referred to related to Python (they have been resolved/closed). But then new ones have been discovered (https://wiki.debian.org/ReproducibleBui ... rch=Titles).
Some have already been fixed (https://bugs.debian.org/cgi-bin/bugrepo ... bug=759231) and others have existing workarounds (https://wiki.debian.org/ReproducibleBui ... ionNumbers). Perhaps we're only a quarter away from being able to build deterministic builds on Debian (but not on Ubuntu?).
Luke-Jr actually notified us of a related issue to that -- by renaming some of that stuff, we made it impossible for Bitcoin's input cache to be reused in Namecoin. We should fix that. But the original issue is fixed AFAIK, at least for the Linux descriptors (I don't remember if I ever tried the Windows descriptors, and I definitely didn't try OS X).somename wrote:While searching for Gitian related stuff I found this: https://www.bountysource.com/issues/841 ... to-bitcoin (a closed issue).
I don't think this is likely to be a problem for Gitian. Gitian intentionally starts each build with a clean VM, specifically for the purpose of eliminating any pre-existing factors that might make the build non-reproducible. It's entirely possible that packages built with Gitian will conflict between Bitcoin and Namecoin when they're installed due to that bug, though... I haven't tried that.somename wrote:Few weeks back when trying to build Namecoin Core 0.11 I encountered a related issue (https://github.com/namecoin/namecoin-core/issues/31). Maybe those who use Gitian for both Namecoin and Bitcoin would run into this issue unless they were to take snapshots or clones of their Gitian environments.