Most active commenters

    ←back to thread

    764 points bertman | 15 comments | | HN request time: 0.318s | source | bottom
    1. abdullahkhalids ◴[] No.43485194[source]
    Is the build infrastructure for Debian also reproducible? It seems like we if someone wants to inject malware in Debian package binaries (without injecting them into the source), they have to target the build infrastructure (compilers, linkers and whatever wrapper code is written around them).

    Also, is someone else also compiling these images, so we have evidence that the Debian compiling servers were not compromised?

    replies(5): >>43485310 #>>43485572 #>>43485619 #>>43486186 #>>43492801 #
    2. jzb ◴[] No.43485310[source]
    There's a page that includes reproducibility results for Debian here: https://tests.reproducible-builds.org/debian/bookworm/index_...

    I think there's also a similar thing for the images, but I might be wrong and I definitely don't have the link handy at the moment.

    There's lots of documentation about all of the things on Debian's site at the links in the brief. And LWN also had a story last year about Holger Levsen's talk on the topic from DebConf: https://lwn.net/Articles/985739/

    3. ◴[] No.43485572[source]
    4. layer8 ◴[] No.43485619[source]
    And what about the hardware on which the build runs? Is it reproducible? ;)
    replies(5): >>43486069 #>>43486115 #>>43486158 #>>43486241 #>>43488837 #
    5. nikisweeting ◴[] No.43486069[source]
    well little johnny, when one hardware loves another hardware very much...
    6. kragen ◴[] No.43486115[source]
    Working on it! But in general the answer is that for most purposes it's good enough to show that many independently produced pieces of hardware can reproduce the same results.
    7. ratmice ◴[] No.43486158[source]
    And who trusting trusted the original RepRap?
    replies(1): >>43489510 #
    8. paulddraper ◴[] No.43486186[source]
    A la xz.

    You must ultimately root trust in some set of binaries and any hardware that you use.

    replies(1): >>43486993 #
    9. abdullahkhalids ◴[] No.43486241[source]
    You are joking. But solving this problem is probably amongst the most important we can have in the information age we live in.

    Every country in the world should have the capability of producing "good enough" hardware.

    10. XorNot ◴[] No.43486993[source]
    For user space? No you can definitely do a stage 0 build which depends only on about 364 bytes of x86_64 binary (though ironically I haven't managed to get this to work for me yet).

    The liability is EFI underneath that, and the Intel ring -1 stuff (which we should be mandating is open source).

    replies(1): >>43493434 #
    11. TacticalCoder ◴[] No.43488837[source]
    > And what about the hardware on which the build runs? Is it reproducible? ;)

    "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers"

    https://dwheeler.com/trusting-trust/

    If the build is reproducible inside VMs, then the build can be done on different architectures: say x86 and ARM. If we end up with the same live image, then we're talking something entirely different altogether: either both x86 and ARM are backdoored the same way or the attack is software. Or there's no backdoor (which is a possibility we have to fancy too).

    12. orblivion ◴[] No.43489510{3}[source]
    The 50th generation builds a robot that murders you
    13. goodpoint ◴[] No.43492801[source]
    The whole point of reproducible builds is to ensure security even if buildbots are compromised.
    14. paulddraper ◴[] No.43493434{3}[source]
    > which depends only on about 364 bytes of x86_64 binary
    replies(1): >>43494146 #
    15. jesboat ◴[] No.43494146{4}[source]
    that's the point at which you say (reasonably accurately) that the 364 byte thing is written in machine code. it is small enough to manually translate between the binary and asm