Re: How to talk to skeptics?
* "Bernhard M. Wiedemann via rb-general" [2022-12-14 20:30]: > a colleague of mine is rather skeptic towards bootstrapping and > reproducible-builds. > [...] > In the end, it would be useful to collect some well-worded / well-thought > counter-arguments on r-b.o (if we don't have that already) > [...] > Any thoughts and/or volunteers? One aspect that I think only Tristan van Berkom explicitly mentioned [1] so far is IMO quite important: bit-by-bit identical binaries must behave identically (or at least if they don't we know the problem lies elsewhere). Even if reproducible builds cannot provide 100% protection against malicious subversion, we know that bit-by-bit identical binaries cannot behave differently, whether through subversion or accident. There can be no bug present in one but not the other, whether the cause is malicious or simply a non-deterministic build process -- or even a random bitflip -- producing subtly different binaries. Non-determinism often hides bugs or makes them harder to find. With RB, you know that any change in a program's behaviour must be caused by a change in its source code and cannot be caused by a "random" difference between different builds, making debugging easier. - FC [1] https://lists.reproducible-builds.org/pipermail/rb-general/2022-December/002789.html
Re: How to talk to skeptics?
I suggest writing a longer paper on "why reproducible builds" and posting it on the r-b website. Here are few quick points from me that might be helpful. In general, we should focus on risk.. but not just current risk, but future risk. It's absolutely *true* that unintentional vulnerabilities in source code are *far* more common. There *are* efforts to counter them & reduce them over time. These also counter "bugdoors"; if a vulnerability is in source, a tool or human reviewer has an opportunity to detect them. If unintentional vulnerabilities aren't addressed, then reproducible builds won't help, and if that's their argument I strongly *agree*. I'm operating under the assumption that over the next few years we're finally going to serious focus on eliminating vulnerabilities in source code. For example, by actually training software developers in how to develop secure software (something we don't currently do), adding tools to detect vulnerabilities, & modifying infrastructure to make vulnerabilities less likely (both in source code and in the supply chain). Asking everyone to recompile source code is *not* a reasonable strategy. Yes, some people will do it, but almost no one does, and that will not change. We need a mechanism that can detect subverted builds *without* requiring everyone to recompile their local copies of software. Reproducible builds does that. It's true that attacks on builds and compilers are rare, but that doesn't mean they'll stay that way. SolarWinds had a subverted build process. And we've already seen a subverted compiler in action. In 2015 it was revealed that over 4,000 Apple iOS applications were subverted and got into the Apple app store through an attack called XCodeGhost. This attack convinced developers to use a subverted version of Apple's XCode development environment. Many popular applications were infected via XCodeGhost, including Angry Birds 2 and WeChat. FireEye estimated that XcodeGhost added malicious code to over 4000 apps. Reproducible builds by themselves counter subverted builds. If you want to counter the trusting trust attack, you need an additional technique, either diverse double-compiling (DDC, the subject of my PhD dissertation) or bootstrappable builds. But that's okay, these are reasonable additions after you have reproducible builds & are worrying about subversion of the underlying build tools (instead of primary build process). As far as hardware subversion goes, obviously that's a different challenge. However, such subversions (especially if they aren't just DoS) are more challenging. Chips are made in factories where there have to be a lot of controls to start with, so while there *are* ways to subvert them, there are also countermeasures. The "simple" solution is to source parts from sources more likely to be trustworthy. Remember, the goal is not to eliminate all possible risk - that is impractical. Instead, the goal is to reduce risks to acceptable levels. We can do a *lot* today to reduce those risks. Today, what's under attack is the software... so let's do our part to counter those attacks. --- David A. Wheeler
Re: How to talk to skeptics?
On 18/12/2022 02.09, Martin via rb-general wrote: Controlling hardware is essential https://www.bunniestudios.com/blog/?p=5706 Covers the topic of why open-source hardware is not enough to build trustable devices. TLDR: there are ways to subvert silicon that cannot be detected, even with a electron-microscope, even if you know where to look. One way out are FPGAs wherein you place processor cores randomly, so attackers cannot know what to subvert at the time of fabrication. However, this is orthogonal to reproducible+bootstrappable builds. Ideally you have all of them, but having some of them, is better than having none. Ciao Bernhard M. OpenPGP_signature Description: OpenPGP digital signature
Re: How to talk to skeptics?
> That's really awesome work like many other out there > https://codeberg.org/StefanK/MinimalBinaryBoot . I hope it won't end > up as yet another failed project that stuck somewhere in the middle of > the road. That really isn't our style, we produce results. Even if it means years of work. > But shouldn't we focus first on fixing the hardware instead > of constantly forking each other with biased software? Why China > developing their own completely new native hardware architectures from > scratch is straggling so much to port any public software on it? Even > in RISCV we have serious issues to bootstrap Guix without > crosscompilation or just to reproduce popular software like Rust, > etc. Is it really so hard even for top world universities to create at > least theoretical model of perfectly libre, formally verifiable and > auditable hardware(linux capable) that could serve as a ground truth > device for further transparent, bootstrappable and reproducible > research? Without this base requirement don't you feel like a surgeon > operating humans that only knows frogs anatomy? I have an impression > that if nothing change in this topic the future history books will > describe our times as an Open-Source big illusion era. Who said hardware wasn't on the table for bootstrappable? We will get to it when people willing to do the work show up. I'll even buy them the tools they need to get that job done. But until we find people willing to do that work; then what would be superior really doesn't matter. I'll even pay to have their design be fabbed. I'm even cool sending money to people so that they can build their own fab to make chips if they are willing to publish their work like the Libresilicon project [ https://libresilicon.com/ ] I would love to see proper hardware bootstrapping being done but until the people willing to do that work show up (or get started on it); then I will use what I have to give people as much freedom as I can. We have created a path to free you from all your binaries except your kernel, firmware and microcode. We are working to free you from your kernel as well (it is hard work and it takes time and skill). And it is already to the level which you can bootstrap to TCC. We will keep going and we will not stop at the software but go straight into the metal and the processes and reveal all the magic to anyone who wishes to know. -Jeremiah
Re: How to talk to skeptics?
December 18, 2022 at 4:20 PM, jerem...@pdp10.guru wrote: > > > > > (i.e. to bootstrap linux from hex0 in practice you need to run it on > > linux anyway https://github.com/fosslinux/live-bootstrap ). > > > > Oh then you missed our latest work: > https://github.com/ironmeld/builder-hex0.git > > We wrote a POSIX kernel in under 4KB of hex0 that we can bootstrap with > a single bootloader binary and it is able to run all the steps needed to > get to TCC. We are currently working on getting it to build a more > powerful POSIX kernel written in C and built by the TCC it can run; with > the hopes of it carrying us all the way to Linux. > > (we have a few hurdles to do first: > https://gist.github.com/rick-masters/54204c0b6b369748b4a1aaf2a4da22cf ) > > But it is a reasonable amount of effort we can certainly do. > > After that, we will solve the hardware problem too ^_^ > > -Jeremiah > That's really awesome work like many other out there https://codeberg.org/StefanK/MinimalBinaryBoot . I hope it won't end up as yet another failed project that stuck somewhere in the middle of the road. But shouldn't we focus first on fixing the hardware instead of constantly forking each other with biased software? Why China developing their own completely new native hardware architectures from scratch is straggling so much to port any public software on it? Even in RISCV we have serious issues to bootstrap Guix without crosscompilation or just to reproduce popular software like Rust, etc. Is it really so hard even for top world universities to create at least theoretical model of perfectly libre, formally verifiable and auditable hardware(linux capable) that could serve as a ground truth device for further transparent, bootstrappable and reproducible research? Without this base requirement don't you feel like a surgeon operating humans that only knows frogs anatomy? I have an impression that if nothing change in this topic the future history books will describe our times as an Open-Source big illusion era. Cheers! Martin
Re: How to talk to skeptics?
Martin via rb-general wrote on Sun, Dec 18, 2022 at 01:09:37 +: > In my opinion the biggest problem is that we are not able to audit and > verify any hardware implementation for this work so it cannot be > trusted at all. Controlling hardware is essential and it cannot be > replaced by virtualization unless it's based on some innovative > blockchain PoW-like crypto agnostic miners. Without at least one > wokring fully libre and formally verifiable hardware reference we are > doomed to fail. We did write about that once: https://reproducible-builds.org/news/2019/04/01/reproducible-builds-twain-Intel-8086-audit-and-Berne-Convention-patches/ Cheers, Daniel (Don't miss the bold red text at the top.) > Moreover the very first linux was bootstrapped by > MINIX, the very first MINIX was bootstrapped by UNIX and ironically it > looks like UNIX was somehow bootstrapped by itself in 1970 (it's a > commercial not reproducible by design product anyway ;). After so many > years all kind of Free and Open-Source Software is still literally > prisoned by vendor-locked hardware, its obfuscated binary seeds and > problematic build environments(i.e. to bootstrap linux from hex0 in > practice you need to run it on linux anyway > https://github.com/fosslinux/live-bootstrap ). The long term > perspectives for Bootstrappable and Reproducible builds doesn't look > optimistic neither: > https://gist.github.com/DavidBuchanan314/a15e93eeaaad977a0fec3a6232c0b8ae > (sooner or later other checksums will be breaked as well). > > Cheers! Martin
Re: How to talk to skeptics?
> (i.e. to bootstrap linux from hex0 in practice you need to run it on > linux anyway https://github.com/fosslinux/live-bootstrap ). Oh then you missed our latest work: https://github.com/ironmeld/builder-hex0.git We wrote a POSIX kernel in under 4KB of hex0 that we can bootstrap with a single bootloader binary and it is able to run all the steps needed to get to TCC. We are currently working on getting it to build a more powerful POSIX kernel written in C and built by the TCC it can run; with the hopes of it carrying us all the way to Linux. (we have a few hurdles to do first: https://gist.github.com/rick-masters/54204c0b6b369748b4a1aaf2a4da22cf ) But it is a reasonable amount of effort we can certainly do. After that, we will solve the hardware problem too ^_^ -Jeremiah
Re: How to talk to skeptics?
December 14, 2022 at 10:52 PM, "Vagrant Cascadian" wrote: > And yes, you eventually get down to how do you trust hardware... there > are a lot of rabbit holes here, and at the end of the day, you need to > prioritize what is the next important thing is, or what gets you the > most value in the short, medium and long term. > > Bootstrappable and Reproducible Builds is probably more in the medium to > long term realm... yet can demonstrate some benefits almost > immediately... if you only focus on the short term, the long-term work > will never happen. I daresay that what the world needs now is a bit more > long-term thinking in general. > > Hello I'm a skeptic as well but I really admire the efforts of all contributors here. At first it looks like some kind of Don Quixote, Sisyphus fight against unfair by design reality but I hope eventually in the future maybe with some external super-AI suport this big transparency issue could be solved completely. In my opinion the biggest problem is that we are not able to audit and verify any hardware implementation for this work so it cannot be trusted at all. Controlling hardware is essential and it cannot be replaced by virtualization unless it's based on some innovative blockchain PoW-like crypto agnostic miners. Without at least one wokring fully libre and formally verifiable hardware reference we are doomed to fail. Moreover the very first linux was bootstrapped by MINIX, the very first MINIX was bootstrapped by UNIX and ironically it looks like UNIX was somehow bootstrapped by itself in 1970 (it's a commercial not reproducible by design product anyway ;). After so many years all kind of Free and Open-Source Software is still literally prisoned by vendor-locked hardware, its obfuscated binary seeds and problematic build environments(i.e. to bootstrap linux from hex0 in practice you need to run it on linux anyway https://github.com/fosslinux/live-bootstrap ). The long term perspectives for Bootstrappable and Reproducible builds doesn't look optimistic neither: https://gist.github.com/DavidBuchanan314/a15e93eeaaad977a0fec3a6232c0b8ae (sooner or later other checksums will be breaked as well). Cheers! Martin
Re: How to talk to skeptics?
Hello all Yes that is true what Tristan wrote. By myself I have introduced reproducible build approaches for controlling software in plants, because I want to know whether the old given sources (from archive) firstly produces the same code which was delivered on plant in the past, before (!) I do some fixes. Why? The possibility that something may be wrong cannot be excluded (faulty include path on build, changed tools, confuse what are the real true sources,...). If the new build delivers the exact same binary (after a long time, on maybe changed environment), only then I am free to work on a fix, without trouble that some trouble comes to me because unknown reasons. After fix the sources, it is also nice to compare for example Object files, or parts of binaries, which should not be changed, whether they are really not changed. The benefit comes on test. In my understandment, if a binary is changed and it is unknown what is impacted, ALL functionality should be tested (a high effort on plant software). But if I am sure that some binaries are not changed, there behavior is expectable the same, and I can prove to the organizers of the plant test, which tests are really necessary, and which should be only tested with reduced effort. And this saves many money (time of test hours) - or can be used with the same time budget to more elaborately test the really sophisticated thinks. That I have done by myself as software developer, only by tuning some conditions for build (for example using anytime exact the same drive and path of sources, the paths are written in Objects, and influences also the binaries) - some years ago. I hope other colleague of this team (I am yet outside) have understand this approach, unfortunatelly it was never in focus of adminstration. Reproducible build seems to be not in focus of software management in most companies. That is the problem. I hope I have well contributed in thinking about this topics. Best regards from Hartmut Schorrig, Germany. My own web page is www.vishia.org Tristan van Berkom schrieb am 17.12.2022 07:04 (GMT +01:00): Hello Bernhard, Due to my propensity to writing overly long and detailed emails, I have refrained until now from ever posting to this list, I'll try to be brief :) Some background, I am an author and maintainer of the BuildStream project: https://buildstream.build/ Which is an integration (build orchestration) tool we developed at Codethink, some of our primary goals are: o Build repeatability: The ability to repeat the build process which led to producing a given build result in perpetuity. o Build reproducibility: Providing an environment which is most conducive to bit-for-bit reproducibility of builds (the reason I follow this list). And various other things, we aim to solve the build problem for complex integrated systems in a way that is decoupled from the payload you are building, instead of being another build solution that is developed as an afterthought of creating a distribution (payload). As such, we have over the years developed some rhetoric in favor or build reproducibility. On Wed, 2022-12-14 at 20:30 +0100, Bernhard M. Wiedemann via rb-general wrote: > Hi, > > a colleague of mine is rather skeptic towards bootstrapping and > reproducible-builds. > [...] I'm mainly posting here today to say that I find it confusing that in the recent couple years, the argumentation in support of build reproducibility on this list appears to have been solely focused on security. I think it started with a thread on this list where it was claimed that reproducibility would have prevented a notorious supply chain attack (which arguably it could have been, and perhaps arguably other measures could have prevented such, and perhaps taking all measures to prevent supply chain attacks is a good idea). While this security related rhetoric is compelling, I feel that it leaves out other important aspects. To my mind, one of the bigger value adds of having reproducibility is in validation, more specifically the avoidance of expensive/extensive validation of build artifacts which have not changed as the result of upgrading some dependencies. While of course unchanged binary executables still require validation against changed execution contexts (e.g. upgraded kernel, or changed adjacent services this binary may talk to over some IPC), simply knowing which build artifacts have changed as a result of some underlying changes brings huge value in validation. Another point worth making in the security and safety related spaces, is that while some arguments can be made for the trust in a binary itself based on its reproducibility in varied build contexts (which seems to be along the lines argued in the "you dont need..." link provided in this thread), there is the opposite argument which can be made that reproducibility itself serves as a valuable interrogation of the supply chain and build environment. In other
Re: How to talk to skeptics?
Hello Bernhard, Due to my propensity to writing overly long and detailed emails, I have refrained until now from ever posting to this list, I'll try to be brief :) Some background, I am an author and maintainer of the BuildStream project: https://buildstream.build/ Which is an integration (build orchestration) tool we developed at Codethink, some of our primary goals are: o Build repeatability: The ability to repeat the build process which led to producing a given build result in perpetuity. o Build reproducibility: Providing an environment which is most conducive to bit-for-bit reproducibility of builds (the reason I follow this list). And various other things, we aim to solve the build problem for complex integrated systems in a way that is decoupled from the payload you are building, instead of being another build solution that is developed as an afterthought of creating a distribution (payload). As such, we have over the years developed some rhetoric in favor or build reproducibility. On Wed, 2022-12-14 at 20:30 +0100, Bernhard M. Wiedemann via rb-general wrote: > Hi, > > a colleague of mine is rather skeptic towards bootstrapping and > reproducible-builds. > [...] I'm mainly posting here today to say that I find it confusing that in the recent couple years, the argumentation in support of build reproducibility on this list appears to have been solely focused on security. I think it started with a thread on this list where it was claimed that reproducibility would have prevented a notorious supply chain attack (which arguably it could have been, and perhaps arguably other measures could have prevented such, and perhaps taking all measures to prevent supply chain attacks is a good idea). While this security related rhetoric is compelling, I feel that it leaves out other important aspects. To my mind, one of the bigger value adds of having reproducibility is in validation, more specifically the avoidance of expensive/extensive validation of build artifacts which have not changed as the result of upgrading some dependencies. While of course unchanged binary executables still require validation against changed execution contexts (e.g. upgraded kernel, or changed adjacent services this binary may talk to over some IPC), simply knowing which build artifacts have changed as a result of some underlying changes brings huge value in validation. Another point worth making in the security and safety related spaces, is that while some arguments can be made for the trust in a binary itself based on its reproducibility in varied build contexts (which seems to be along the lines argued in the "you dont need..." link provided in this thread), there is the opposite argument which can be made that reproducibility itself serves as a valuable interrogation of the supply chain and build environment. In other words, having reproducible builds in your organization can be used as evidence to demonstrate that your organization does indeed have strict control over all build inputs and infrastructure, and non- reproducible outputs serves as an alarm which tells you that something might be compromised (non-deterministic contaminants were introduced somehow, perhaps by way of random source code/data being downloaded from the internet). I'll also provide this link to an article by our team, outlining a project where build reproducibility played a large part in our ability to acquire an ISO 26262 certification: https://www.codethink.co.uk/articles/2021/deterministic-construction-service/ Feel free to take or leave anything from this, just felt by now it was time to throw in 2 cents ;-) Cheers, -Tristan
Re: How to talk to skeptics?
On 12/14/22 11:30 AM, Bernhard M. Wiedemann via rb-general wrote: He also once pointed me to https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html By the way, I think this person's argument falls apart here: "The only way to verify that the untrusted binary is bit-for-bit identical to the binary that would be produced by building the source code, is to produce your own trusted binary first and then compare it. At that point you already have a trusted binary you can use, so what value did reproducible builds provide?" That makes the incorrect assumption that a build you create yourself can always be trusted. On the contrary, no single build can be trusted because it's too easy to compromise a single build environment. That's the benefit of verified reproducible builds: an attacker has to compromise several different build environments on different machines and networks and in different countries. So the second diagram on the page does not create a trusted binary. You still want to keep the other build for comparison instead of throwing it in the trash. John
Re: [bootstrappable] How to talk to skeptics?
On Wed, Dec 14, 2022 at 11:00:49PM +, jerem...@pdp10.guru wrote: > But for the people who do choose to trust binaries, reproducible builds > is the only option you have to check if the source and the binaries > correspond. Yes, and in addition reproducible builds are also a way for people who do not know each other to agree that they are talking about the same thing. These strangers may have independently built a wrong or bad thing. But they can know they have built the same thing, and that is a very valuable starting point. Therefore reproducible builds are one important way of introducing scientific method to the world of software. > choosing to make our work reproducible and having a clear bootstrapping > path, is a way of showing we care about others. The above sentence stands alone and is excellent, highlighting that software harms people, and we want to reduce the harm because we care about the people. I found the rest of you analogy a little strained and approximate, but I'm going to adopt this sentence for my own use. Thanks :-) -- Dan Shearer d...@shearer.org
Re: [bootstrappable] How to talk to skeptics?
> We already fully trust the sources they release, and we already fully > trust their binary compiler releases. Well that assumption is 100% wrong. Trusting source code is the wrong place to place trust. And trusting binaries is just a bad idea in general. But for the people who do choose to trust binaries, reproducible builds is the only option you have to check if the source and the binaries correspond. And even that comes with restrictions to make it semi-safe. Think of Reproducible builds as condoms; used incorrectly it doesn't protect you. But proper use reduces the risks you are exposed to if you choose to trust binaries downloaded onto your system. Then think of Bootstrappable builds as STD contract tracing; if none of the people you have sex with has Herpes and you know everyone they had sex with back until the dawn of time, there is no way for you to get herpes from the actions you engage in, even if they aren't reproducible (no condom used). In an ideal world, we would be bootstrapping entirely from a seed we ourselves make in a few hundred bytes toggled into memory. But we need to be practical because other people will never choose to do that. So choosing to make our work reproducible and having a clear bootstrapping path, is a way of showing we care about others. Giving those engaging in risky behaviors a better chance of not catching anything they don't want or didn't opt into. But that is just my biased (as fuck) view on this. -Jeremiah
Re: How to talk to skeptics?
On 12/14/22 11:30 AM, Bernhard M. Wiedemann via rb-general wrote: He also once pointed me to https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html I also wonder how all this verification is going to work. For example, I'll soon be providing reproducible builds of OpenJDK. How will I recruit volunteers to verify my builds? Is it enough just for me to verify them on a separate build machine and network? Should I instead be matching Oracle's builds of OpenJDK? To do so, I would have to set the "java.vendor" of my build to "Oracle Corporation", but that doesn't seem right. Lots of questions! :-) In the end, it would be useful to collect some well-worded / well-thought counter-arguments on r-b.o (if we don't have that already) The link below is my latest attempt at persuasion: Discussion: Reproducible builds https://mail.openjdk.org/pipermail/openjfx-dev/2022-December/037412.html I'd like to think that my arguments worked, now that my two-year-old pull request is tentatively planned for the next release. In reality, though, I find that most of the resistance to reproducible builds is not technical, but rather due to time constraints and business plans. It takes a lot of time to test reproducible builds. When I update my pull request, I have to run about 30 builds covering three operating systems and six hardware platforms, and reviewers have to do something similar. That's a lot to ask of an active project with many competing pull requests. In the extreme, I see reproducible builds as the final step in the commoditization of open-source software. When every package of a project is bit-for-bit identical to every other, it doesn't matter where you get it. That makes it more difficult for any particular vendor to sell the "trust" in its brand. John
Re: How to talk to skeptics?
On 2022-12-14, Bernhard M. Wiedemann via rb-general wrote: > a colleague of mine is rather skeptic towards bootstrapping and > reproducible-builds. > > E.g. he wrote > > https://fy.blackhats.net.au/blog/html/2021/05/12/compiler_bootstrapping_can_we_trust_rust.html This seems to miss the point that the sources *are* auditable, even if after the fact, even if imperfectly, whereas the binaries are orders of magnitude harder to audit. Also curious how to address the bootstrapping problem if a compromised binary ever worked its way into your blind trust of the upstream provided binary compiler? Even if downstream distributions such as OpenSUSE bootstrap from a binary upstream compiler with each new rust version, I sure would hope that upstream can *prove* beyond a reasonable doubt that what they produced is legit in an auditable way... and while I am biased, it seems a bootstrappable and reproducible build is the best current known way to have very high confidence... That many people use rustup to install rust and nothing has (noticeably) gone horribly wrong yet does not win me over in any argument regarding security. The https://rustup.rs recommendation of: curl ... | sh ... is relying on the weakest link in the chain of "trusted" certificate authorities; a security vulnerability that is not so much a back door vulnerability, as a wide open front door with the lights on in the dead of night. The argument that you can't trust the source code is a valid and important concern, but outside the scope of reproducible builds, and there are ways of addressing that through peer review of source code, independent third-party review, and fastidious audit logs of who committed what. The bugdoor argument kind of falls down eventually, because logically, if someone can trivially inject plausible but incorrect source code (and well... I guess they can), why bother reviewing source code at all? Why bother tracking who committed it at all? Since it is impossible to perfectly review source code, may as well not do any kind of review at all... right? Uh, no. All review and auditing processes will catch some bugs, and all security measures raise the bar by some degree... using all known best practices will catch as much as we can plausibly catch with our non-infinite resources, despite being imperfect. I wonder if the reproducible builds focus on bit-for-bit identical perfection gets peoples head stuck in the idea of perfection in all ways? While bit-for-bit identical builds are possible, we do not claim it is absolute, incontrovertable proof of a perfect build. It just just one measure of confidence amoung many. A good measure, in my opinion, but just one tool. Compromised compilers most definitely have been released into the wild. It is getting a little old now, but XcodeGhost (a.k.a. Strawhorse) falls squarely into this category: https://en.wikipedia.org/wiki/XcodeGhost Even without more current examples, even though it is difficult to pull off... it is clearly possible, has been done, and been executed by well funded entities in the past... and is, by design, hard to detect. I have no reason to believe that was a one-off playground experiment. And yes, you eventually get down to how do you trust hardware... there are a lot of rabbit holes here, and at the end of the day, you need to prioritize what is the next important thing is, or what gets you the most value in the short, medium and long term. Bootstrappable and Reproducible Builds is probably more in the medium to long term realm... yet can demonstrate some benefits almost immediately... if you only focus on the short term, the long-term work will never happen. I daresay that what the world needs now is a bit more long-term thinking in general. > and the effect can also be seen in his packaging such as > https://build.opensuse.org/package/show/openSUSE:Factory/rust1.65 > that ships with two gigabytes of bootstrap compiler binaries for various > architectures instead of using our existing rust packages of version N-1 > "because compilation takes twice as long". > > He also once pointed me to > https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html And for a more light-hearted take... You don't *need* computers either. :) In a similar vein: https://xkcd.com/2368/ Especially I think the alt-text nailed it. > In the end, it would be useful to collect some well-worded / > well-thought counter-arguments on r-b.o (if we don't have that already) > > https://reproducible-builds.org/docs/buy-in/ could provide some input. > > Any thoughts and/or volunteers? I think Morten Linderud had really good points when this came up before: https://lists.reproducible-builds.org/pipermail/rb-general/2020-August/002008.html live well, vagrant signature.asc Description: PGP signature
How to talk to skeptics?
Hi, a colleague of mine is rather skeptic towards bootstrapping and reproducible-builds. E.g. he wrote https://fy.blackhats.net.au/blog/html/2021/05/12/compiler_bootstrapping_can_we_trust_rust.html and the effect can also be seen in his packaging such as https://build.opensuse.org/package/show/openSUSE:Factory/rust1.65 that ships with two gigabytes of bootstrap compiler binaries for various architectures instead of using our existing rust packages of version N-1 "because compilation takes twice as long". He also once pointed me to https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html In the end, it would be useful to collect some well-worded / well-thought counter-arguments on r-b.o (if we don't have that already) https://reproducible-builds.org/docs/buy-in/ could provide some input. Any thoughts and/or volunteers? Ciao Bernhard M. OpenPGP_signature Description: OpenPGP digital signature
