Hacker News new | past | comments | ask | show | jobs | submit login

This is why I love the approach taken by Debian (and most other distros).

Although they provide binary packages, they insist on building everything from source, independently from the upstream projects such as Bitcoin. Moreover, the build process itself must be able to run entirely with Free Software. And the same must hold for all dependencies. Otherwise a package can't make into their "main" distribution (just into "contrib" or "non-free", but users of these parts are warned).

That way, an attacker can't simply tamper with binaries. They have to distribute the manipulates sources instead. Although that kind of attack may still be feasible, it requires a lot more openness from the attacker than just changing sources privately and distributing merely faulty binaries.

This will be futher hardened by Debian's initiative to provide reproducible builds, so that if one of their many build servers is compromised, this can be detected by simply comparing hashes of the resulting binary packages produced by other build servers and/or local build of the maintainers or any curious user:

https://wiki.debian.org/ReproducibleBuilds

Speaking of Debian, unfortunately Bitcoin never made it beyond Debian/Unstable (Sid), because the Bitcoin release process appears to be incompatible with the Debian release process, especially regarding backporting security fixes, so the Debian people decided to be better safe than sorry:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718272




Isn't it harder to hash every single file in source? There's thousands


Debian simply hashes the source tarballs, then signs these hashes and some metadata, just like everybody else does.

For example:

http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0....

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    Format: 3.0 (quilt)
    Source: bitcoin
    [...]
    Checksums-Sha256:
     aab2cd0c4f045970d259cf9fcee5785b43180d20ccbbedc1f90480e697696b25 5955398 bitcoin_0.11.2.orig.tar.gz
     e294975cd99a90c0750255303b51a9d3058a4e2e16087c6450908d7d64581772 33880 bitcoin_0.11.2-1.debian.tar.xz
    
    -----BEGIN PGP SIGNATURE-----
    [...]
    -----END PGP SIGNATURE-----
Here, bitcoin_0.11.2.orig.tar.gz is the original source tarball as downloaded from the Bitcoin project, and bitcoin_0.11.2-1.debian.tar.xz is the tarball that contains all Debian specific adjustments.


huh?

"when will we finally throw away binary uploads" https://lists.debian.org/debian-devel/2014/02/msg00622.html

"For instance, when a maintainer uploads a (portable) source packages with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 11 more builds." https://www.debian.org/doc/manuals/developers-reference/pkgs...


Care to elaborate?

I do not see how the quoted text snippets contradict what I wrote (that Debian builds binary packages fully indepdently from upstream, and prepares to have reproducible builds in the future).

Moreover, a single "huh?" comment is almost never helpful for a civil conversation.


how does debian developers independently building on their machines help? if anything it adds another point of failure. if you trust upstream enough to run their code, you implicitly trust the state of their hardware anyway (since nobody has the time to completely grasp any reasonably large codebase in its entirety); so it seems sensible to trust their builds more than some random debian maintainer


> if you trust upstream enough to run their code, you implicitly trust the state of their hardware anyway

No, these are fundamentally different levels of trust.

Note that we are talking about a breach-in into the webserver, not into a developer's private computer.

For example, some time ago there was a breach-in into the Linux Kernel website. It had almost no effect on the security of this project, because so many people had the sources, and because the Git commits are signed by the authors.

So not only were the attackers unable to distribute their binaries. They were also unable to place malicious commits into the source code. And this was mainly because every distro builds their Linux kernel on their own (and also because sources are signed by the developers and reviewed by multiple developers, although that's not the point of discussion here).

The breach-in into the Bitcoin webserver could have been similarily effect-less, if they were as well-organized as the Linux kernel and worked better together with the distros.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: