Live data from Hacker News

Bootstrappable Builds: How and Why

lwn.net

41–50 of 62 posts

Re: Bootstrappable Builds: How and Why

#41

Earlier quoted context omitted.

This thinking keeps open source behind competitors. Additionally this person is not just wasting his own time, but through both just this talk and the contents of it where he asks others for help it is causing other people to get involved with this waste of time.

You seem to be missing the part where this is all people voluntarily doing things that they deem are important to themselves or just plain fun to do. No one commands open source developers to do the things they do, they do them because they have an itch to scratch and are kind enough to release that work for other people with the same itch. Your view is very much "What I think they should do is more important than wh…

There are more itches for these people to scratch than this problem. Volunteer's time is both valuable and limited and it is a shame when it is wasted when those resources could have been used on something that actually makes the product better.

>"What I think they should do is more important than what they think they should do" and that's not how that works.

Again within his talk he is trying to get people to work on what he thinks is important instead of what they would otherwise be doing. Is he entitled for that? I don't think so. Trying to align people with your vision to try and accomplish things is just a part of life and I do not see it as entitlement. Society is one big optimization problem and arguments like this is a part of how the optimization process works.

Re: Bootstrappable Builds: How and Why

#42
post #35

Earlier quoted context omitted.

>People can still pursue their hobbies and sharpen their programming skills by working on more productive issues that exist. No, they can't. People pursue things that interest them, if it isn't interesting they wouldn't do it at all. This is similar to "why donate to cause X when cause Y is much more important?" well if cause X didn't exist, those people likely wouldn't donate at all, so it's not really an opportunit…

Except I'm not saying there is only X and Y. I'm saying there is AAAAA-ZZZZZ and people working on problem XYZAB would be able to help actually push these operating systems forward if they chose another problem they also found interesting. I do not believe that it is only possible for these people to be interested in a single problem. I think these people can be motivated to find another problem more interesting.

> I think these people can be motivated to find another problem more interesting.

You can pay them I guess, usually a good motivator.

Re: Bootstrappable Builds: How and Why

#43

Are chain-of-trust attacks real? Is it necessary to make so much effort to avoid what supposedly never happened?

Back in middle to late 2000s, me and my friend discovered that our Delphi 7 installations were infected by Induc.A, which infected the compiler by registering a pascal module and including itself in all the builds compiler produced.

We traced the infection back to a legit software build (it was either AIMP player or QIP messenger, I don't remember already), that was apparently built with an infected compiler.

Re: Bootstrappable Builds: How and Why

#44
post #40

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

This project is not pointless at all. It's not about "reproducible builds", but about building a full present system from "first principles". It would be a way out of a significant dependability problem barely anyone today is aware of.

>way out of a significant dependability problem

This is not an actual problem. It is a made up problem that acts as honey attracting people to obsess over it.

Re: Bootstrappable Builds: How and Why

#45
post #42

Earlier quoted context omitted.

Except I'm not saying there is only X and Y. I'm saying there is AAAAA-ZZZZZ and people working on problem XYZAB would be able to help actually push these operating systems forward if they chose another problem they also found interesting. I do not believe that it is only possible for these people to be interested in a single problem. I think these people can be motivated to find another problem more interesting.

> I think these people can be motivated to find another problem more interesting. You can pay them I guess, usually a good motivator.

That is one way, but there are other ways to motivate and demotivate people.

Re: Bootstrappable Builds: How and Why

#46
post #39
post #3

Earlier quoted context omitted.

I am working on this![0] But this is actually a herculean task, I've been chipping at it for weeks and even trying to cheat somewhat by translating mrustc from C++ to C89. If anyone has ideas/cheaper ways to run it I would like to know. In the meantime, months ago I achieved bootstrap of TCC (then GCC 4.6) via the same path as the live-bootstrap project but replacing the Scheme part with a C compiler in Ben Lynn's Ha…

> If anyone has ideas/cheaper ways to run it I would like to know GCC 4.7.4 was the last version of GCC fully written in C, with full C++98/03 support and a decent subset of C++11. As far as I know it is used by the bootstrap project presented in the article.

Specifically the expensive part is getting a C89 port of mrustc to compile rustc 1.90.0. mrustc needs C++ right now, bootstrapping via TCC by writing it in C89 would be the shorter chain.

Re: Bootstrappable Builds: How and Why

#47
post #40

Earlier quoted context omitted.

This project is not pointless at all. It's not about "reproducible builds", but about building a full present system from "first principles". It would be a way out of a significant dependability problem barely anyone today is aware of.

>way out of a significant dependability problem This is not an actual problem. It is a made up problem that acts as honey attracting people to obsess over it.

Well, it might not be your actual problem. But there are always people who look a little further beyond the horizon.

Re: Bootstrappable Builds: How and Why

#48
post #38
post #30

Earlier quoted context omitted.

The more I think about it, the more I think that bootstrapping the build isn't actually the huge problem it first seemed to be. There are practical problems to solve, but they CAN be solved. In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes…

>as long as you run it on your own trusted hardware and verify the signature first. I think that depends how far you want to take the paranoia. In principle if you want that to be a secure signature that can't be forged, you're back to needing both hardware and software you trust to verify the signature. Hashing a large binary and verifying a signature on paper is wildly impractical. If someone prints the code and cl…

> because you're not going to be verifying that signature by hand

At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that.

> Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first. > > But then you're back to needing a clean bootstrap again. (...)

But having solved that bootstrapping problem, you are likewise back to square one with trusting "the payload", only this time the payload isn't the actual payload but the OS kernel, UEFI or whatever that obtains and verifies the actual payload.

You have that OS kernel or UEFI as source code, but you don't know if the source code contains a backdoor unless you either verify it manually, or have it verified and signed in some way by a third party you trust, and there the whole signature thing comes back.

(BTW thanks for the discussion. I'm really enjoying this!)

Re: Bootstrappable Builds: How and Why

#49

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

This is probably not a convincing argument, but I'll share it anyway.

Think of bootstrapable builds as a hedge against tyranny.

Is it likely that a future regime could come into being that would be backdooring FLOSS builds and undermining confidence in the entire ecosystem? Not at all likely, as this requires a purge of all the install/boot media already out there.

Though after the passage of decades, the chain of custody starts to weaken. Maybe I'll still believe in the magic of the CD in my retro closet with the three humans holding hands in a circle, but in an environment where children are told to report the thoughtcrimes of their elders, how can my nephews and nieces in turn trust me and my testimony that my copy is the "good stuff" from "the before times".

This is all very far fetched sci-fi material, but think in terms of tail risk, low probability multiplied by a high cost if comes to pass.

Perhaps a regime horrible enough to break FLOSS would be horrible enough to purge all legacy hardware and software sitting in closets, but I do think it is easier to mess up the internet and the social fabric than it is to do house to house cleanouts.

Maybe messing around with untainted FLOSS will be too dangerous in such an environment anyway, but if we can assume a state of liberty eventually returns, having a great bootstrap ready to go can help rebuild society, cyberspace, and trust on an accelerated basis.

All of this hinges on people actually auditing source code, though once you've read enough bootstrapped source to have confidence in the generation of checksums you can at least start to fall back on a social consensus as to the safety of additional source archives that have known checksums and from there also digital signatures once you've built the tools for validating those.

When it comes to "trust, but verify" of other people's source code, there is a new tool in the toolbox: large language models have demonstrated some considerable audit value. Of course almost nobody is training their own models and it's only a slightly larger circle that does inference on their own hardware or attested remote hardware, but all of this is at least something that can increase confidence when working from other folks source code.

-------

As far fetched as full on cyber tyranny sounds, its worth remembering that in North Korea this is actually reality. Folks do not have access to the internet and are handed the state built binary of Red Star OS.

The ballooning of flash drives containing western media is still a thing despite attempts to stop it.

It is unlikely that anyone will ever send in a software bootstrap, that it will get in the hands of someone who can understand it, have the time to read it and build it.

But the scenario does make us think about the value of bootstrapable FLOSS as a tyranny hedge.

Without real internet access, what good does having some freedom on a computer even do? I suppose one can keep a diary encrypted, though possessing an encrypted file is probably more of a liability than any value it provides. Someone may also find encryption helpful for friend to friend networks by sneakernet, though the downsides are considerable.

Someway, somehow the regime may fall. After decades of not trusting the outside world and being governed by a hostile state, perhaps there will be at least one deeply computer literate person to emerge from that place who will appreciate being able to bootstrap their own personal cyber citadel.

Re: Bootstrappable Builds: How and Why

#50
post #46
post #39

Earlier quoted context omitted.

> If anyone has ideas/cheaper ways to run it I would like to know GCC 4.7.4 was the last version of GCC fully written in C, with full C++98/03 support and a decent subset of C++11. As far as I know it is used by the bootstrap project presented in the article.

Specifically the expensive part is getting a C89 port of mrustc to compile rustc 1.90.0. mrustc needs C++ right now, bootstrapping via TCC by writing it in C89 would be the shorter chain.

Sounds pretty difficult (if not impossible, see cfront 4.0) to translate C++ code to C89. You have to keep track of all constructors and destructors and their progress along the body yourself, and I assume it must be fit for exceptions as well?
Post reply on HN