Live data from Hacker News

Bootstrappable Builds: How and Why

lwn.net

61–62 of 62 posts

Re: Bootstrappable Builds: How and Why

#61
post #58
post #48

Earlier quoted context omitted.

> 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 UEF…

I was thinking an FPGA with an open toolchain might make a pretty solid hardware seed that can fairly easily be replicated, without needing your own fab or anything completely impractical. In theory the FPGA could still try to recognize and backdoor a bitstream right when you load it, but practically there's a whole bunch of different open-source cores that you could load on the FPGA, and it would be very hard to try…

Isn't a sectorlisp running on a microcontroller a more straightforward solution? Detecting and modifying a sectorlisp on the fly would require something like a frontier LLM with latency on the order of fractions of a second.

Re: Bootstrappable Builds: How and Why

#62

Browser extension is same problem but smaller. The .crx file is just a zip, so anyone can open it. But almost everything in the store is bundled and minified. You can read it, but you are reading the output of a build you did not run. So I made mine with no build step at all. The files in the repo are the files that run. Reason is simple. My extension reads cookies, and I could not find other way to let someone confi…

This is the way!

I have some websites (like https://correcthorse.org) that need the users full trust and thus rely on minimal unobfuscated JS so that you can easily verify all the code that gets run by looking at the source and the approximate 10 or 20 lines of clear JS.

Post reply on HN