bitcoin - adopt mainstream binaries

[anddam (Andrea D'Amore)]

​This document explains a rationale about using only official Bitcoin images in order to provide a coherent set of clients.

Due the delicate nature of bitcoin software, potentially affecting users' money in a direct way, this should be taken in consideration.

Two scenarios that come to mind about how to approach this are:

• disable the port at all and print out a message redirecting the users to official binary packages;
• fetch the binary and signed official package and create the MacPorts package from that.

The latter solution keeps the advantage of using a package manager (install, uninstall, upgrade) while giving away the actual build part.

Please provide your thoughts.

[easye]

For my use of BTC (and open source software under OS X in general), I want to compile from the source for which I can verify PGP signatures. I use MacPorts specifically so I can share the work of maintaining build infrastructure with other developers.

If you want to fetch the binary, please maintain a path so that I can compile from source.

You will need to audit the chain of trust for verifying the official Bitcoin binaries.

Is there another example of a MacPort which fetches and verifies official binaries?

[anddam (Andrea D'Amore)]

Replying to easieste@…:

For my use of BTC (and open source software under OS X in general), I want to compile from the source for which I can verify PGP signatures.

This despite the Bitcoin core request? This is a case where the functionality of the network as a whole is affected by subtle differencies.

I use MacPorts specifically so I can share the work of maintaining build infrastructure with other developers.

The drawback of doing this is that in the case of the heartbleed bug the 0.9.1 upgrade would have been useless if the openssl port hadn't been upgraded to 1.0.1g already. Even worse this could have given a false sense of security.

You will need to audit the chain of trust for verifying the official Bitcoin binaries.

I don't like fetching the binary myself but this is a case where this kind of request could actually make sense, and it comes from upstream core developers team.

Also the trust chain wouldn't be very different, the code is still available and you'd be fetching a signed binary from one of the authors. That's the actual trust part you're giving and it's not any worse than building a source tree without reading it but relying on it's openness as a guarantee of trust.

Another scenario could be a (bitcoin-mp, bitcoin) pair of ports or maybe just a +macports variant providing the required flexibility to users willing to build or to patch their client package. This would compromise both requirements.

[easye]

Replying to and.damore@…:

Replying to easieste@…:

For my use of BTC (and open source software under OS X in general), I want to compile from the source for which I can verify PGP signatures.

This despite the Bitcoin core request? This is a case where the functionality of the network as a whole is affected by subtle differencies.

I believe the Bitcoin core request is somewhat misguided: they need to decide whether they want to develop as open source or not.

Satoshi Bitcoin is not the only peer running on the network: it is a collaborative, evolving effort akin to bittorent. As such, bitcoin peers need to be heavily defensive in their coding practices about sanitizing their input. If you spend some time analyzing bitcoin peer traffic at a network level, you will notice great deviations in format, some of which is obviously (to me) attempts to force other peers to misbehave. This will not change if Bitcoin Core forces "everyone" to use signed binaries.

From my experience (with its associated prejudice), it is much more likely that someone will tamper with the "official binaries" rather than the source. There have certainly cases of people injecting malicious code in open source code, such as the code in the Linux kernel network drivers in the late 90s that was disguised as assembly which responded to an specifically crafted ICMP packet by listening on a port with a root shell. This exploit went undetected for some 18 months, but I would argue that its acceptance into the Linux kernel was a product of the Linux community's (at that time) attitude/policy around patches. Such an exploit has never been detected in FreeBSD, which has always had much more "professional" attitude towards code submissions (and an official "Security Officer"). So, obviously just because something is built from open source does not guarantee that it is secore. But I believe that the value in open source lies in a shared, agreed upon source that can be hashed for verification, to produce binaries. Only from this model where a sizable number of parties actually build and use the thing, we will converge on greater security.

I use MacPorts specifically so I can share the work of maintaining build infrastructure with other developers.

The drawback of doing this is that in the case of the heartbleed bug the 0.9.1 upgrade would have been useless if the openssl port hadn't been upgraded to 1.0.1g already. Even worse this could have given a false sense of security.

I would have contributed to the upgrade of openssl under MacPorts. As such, others in the MacPorts commit community beat me to updating the port. I think the response time to the heartbleed bug strengthens my case for running software compiled from source for which build recipes are maintained in a distributed fashion.

You will need to audit the chain of trust for verifying the official Bitcoin binaries.

I don't like fetching the binary myself but this is a case where this kind of request could actually make sense, and it comes from upstream core developers team.

Also the trust chain wouldn't be very different, the code is still available and you'd be fetching a signed binary from one of the authors. That's the actual trust part you're giving and it's not any worse than building a source tree without reading it but relying on it's openness as a guarantee of trust.

The fact that the source is hashed, cryptographically signed, and run by many parties is the game-theoretic part that makes open source *more* trustworthy in the long run than running binaries.

Another scenario could be a (bitcoin-mp, bitcoin) pair of ports or maybe just a +macports variant providing the required flexibility to users willing to build or to patch their client package. This would compromise both requirements.

That's cool with me: as long as we leave a possibility of building the Satoshi Bitcoin code from source in MacPorts, as that's what I will contribute to maintaining.

[anddam (Andrea D'Amore)]

Replying to easieste@…:

Satoshi Bitcoin is not the only peer running on the network

While I agree on your whole reply this is the real selling point for me and I now agree we should keep building from source.

When reading the note I was somehow thinking of the Bitcoin Core as the only wallet software, ignoring all the others. It'd be unreasonable to ask all of the latters to have the same dependencies, the protocol should be resilient at a higher level than the single client implementation.

I think part of the rationale for the note linked in description is that the core team defines both the protocol and the implementation of a client labeled "Bitcoin Core".

I'm closing this as wontfix.