Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V3VbN-00062C-4F for bitcoin-development@lists.sourceforge.net; Sun, 28 Jul 2013 18:21:53 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.68 as permitted sender) client-ip=74.125.83.68; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f68.google.com; Received: from mail-ee0-f68.google.com ([74.125.83.68]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V3VbL-0003f3-A4 for bitcoin-development@lists.sourceforge.net; Sun, 28 Jul 2013 18:21:53 +0000 Received: by mail-ee0-f68.google.com with SMTP id d41so1489654eek.3 for ; Sun, 28 Jul 2013 11:21:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.47.134 with SMTP id t6mr2069052eeb.141.1375035704933; Sun, 28 Jul 2013 11:21:44 -0700 (PDT) Received: by 10.223.12.131 with HTTP; Sun, 28 Jul 2013 11:21:44 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jul 2013 18:21:44 +0000 Message-ID: From: John Dillon To: Gregory Maxwell Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V3VbL-0003f3-A4 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Linux packaging letter X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:21:53 -0000 My signature: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Linux distribution packaging and Bitcoin ======================================== 2013-07-23 This note summarises the dangers inherent in the Linux distribution packaging model for Bitcoin, and forms a request from upstream maintainers to not distribute Bitcoin node software as part of distribution package repositories without understanding the special requirements of Bitcoin. Distributors typically unbundle internal libraries and apply other patches for a variety of generally good reasons, including ensuring that security-critical fixes can be applied once, rather than multiple times for many different packages. In most cases, the common distribution packaging policy has many advantages. However, Bitcoin nodes are an unusual category of software: they implement a complex group consensus in which every client verifies the behaviour of every other exactly. Even an exceptionally subtle change - including apparently harmless bugfixes - can cause a failure to reach consensus. A consensus failure of one client is a security risk to the user of that client. A significant number of nodes failing to reach consensus - as happened in March 2013 due to a change in database libraries[1] - is a critical problem that threatens the functionality and security of the system for all users. For this reason, it is _vital_ that as much of the network as possible uses _unmodified_ implementations that have been carefully audited and tested, including dependencies. For instance, if the included copy of LevelDB in bitcoind is replaced by a system-wide shared library, _any_ change to that shared library requires auditing and testing, a requirement generally not met by standard distributor packaging practices. Because distributed global consensus is a new area of computer science research, the undersigned request that distributors refrain from packaging Bitcoin node software (including bitcoind and Bitcoin-Qt) and direct users to the upstream-provided binaries instead _until they understand the unique testing procedures and other requirements to achieve consensus_. Beyond being globally consistent, upstream binaries are produced using a reproducible build system[2], ensuring that they can be audited for backdoors. 1. https://en.bitcoin.it/wiki/BIP_0050 2. http://gitian.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WC5AAoJEEWCsU4mNhiPg6UH/2oHzBWBPaQMhH/GCTHQEi5U 7GSRfqwihIs/M2ROHLNq0HhgWR7mPAh5TTI6+tG95FCGCGNZq0seqw9wW4ZyGCoc VueY51q4hcn23405oLD/QGK2lDxxywWY8XtFYVPqAzXTq6zRzgpNJkjoRtOAUOP7 3PrRkimYYyj0KrqFg+cEvZDT27dkeX+5PXM6Ua0o7h/TlhR2RJPhej5DI8cNLXgA f0t+mES4Apb6zLgnEYYlPp22FR9vuFcJO3z1akhVL4DLUMqr58NYHLVnH1FH0Jhn hVuld159QtCjQ5Qyn19cn86akTQJVi+ikCXqaKriCc2jBFX7TCI8WTDc6aSZpsQ= =oX5d -----END PGP SIGNATURE-----