[MacPorts] #43297: bitcoin - adopt mainstream binaries

[MacPorts]

#43297: bitcoin - adopt mainstream binaries
--------------------------------+------------------------
  Reporter:  and.damore@…       |      Owner:  easieste@…
      Type:  enhancement        |     Status:  new
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:  2.2.1
Resolution:                     |   Keywords:
      Port:  bitcoin, bitcoind  |
--------------------------------+------------------------

Comment (by easieste@…):

 Replying to [comment:2 and.damore@…]:
 > Replying to [comment:1 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/43297#comment:3>
MacPorts <http://www.macports.org/>
Ports system for OS X