(Two different emails are cited below.) >On Mon, 13 Jul 2026 18:43:58 +0200 >[email protected] wrote:
> So we are back to learning/teaching as the only rational (in contrast > to emotional) reason to do development of bootstrapping. Certainly, it is not logically necessary to bootstrap the new system. Yet, ordinarily, a newly invented system will at some point bootstrap itself to prove it's sufficiently capable to carry the full load of information processing. Let's not limit ourselves to only some modes of thinking, especially because at one point you yourself reject the notion VSOBFS can serve it's purpose without bootstrapping. It's in the Limits to Verifiability document, under the heading "What about reducing the a priory trusted set?" All of the quibbling is merely if you have to start with hand-assembled code or if you can do consensus heuristics. And I for one reject the idea we can use heuristics for things as important as these, thought I don't deny their utility. > What you analyze was your guesses and not what VSOBFS does. I hope > that reading [2] will clear the picture. Now that I did gain access to Codeberg, it turns out I wasn't really wrong. The only difference was that I assumed you'd require perfect agreement across the entire build fleet, whereas you only required a majority of builders to agree. As far as I'm concerned, this allowance for merely majority "consensus" is a severe problem. I assumed VSOBFS is more secure than it really is. Take for instance the systems on which I might run VSOBFS: two laptops from mid-2000's, one of which is almost guaranteed to house an implant, another laptop and two desktops from late 2010's and an old Olivetti M24. The ONLY system here I'd even remotely trust is the Olivetti, and it's in the minority. Thus, following your prescriptions, if the Olivetti is the sole one that produces a different binary, I'd be required to discard it's output and take the "consensus" one? >On Mon, 13 Jul 2026 18:43:58 +0200 >[email protected] wrote: > It can only if you assume it to be feasible to silently and > successfully corrupt a majority of platforms suitable for checking > VSOBFS (among others all the current major platforms), with a payload > specifically directed to subvert and fake the outcome of VSOBFS. I assume that. Now what? And it's not an idle assumption, either. Remember how STUXNET was discovered? On a CD sent to Russian researches after a professional conference they were on. Have we forgotten NSA's TAO? You're not paranoid if you think "they" are able to infect vast swathes of computers. Here's another one: back in 2012, a dude infected most of home routers to "conduct a census of Internet", the Carna botnet. The thing most people overlook was that the Carna botnet guy *discovered another botnet* on about half of routers he infected! Not to mention the Go compiler injects telemetry into it's output by default. The corruption is not silent, not really. And let me not tell you of a story I heard, of a US laborer working for a German router manufacturer, who for years added an additional chip to the routers he was assembling. And then disappeared into USA when his machinations were discovered. But that is a story I heard from a fellow participant in a security seminar a bunch of years back. Carna, TAO and TPM were/are real. I myself have at one point witnessed the existence of a TCP-terminating function in a router used by a web-coding shop. That's not something such routers ordinarily posses. Was it infected? I also posses a laptop (currently in parts but could be reassembled) that has a two-core CPU, yet which reports only a single core internally to the OS. To make matters more interesting, it's chipset has never been documented as being able to support multi-core CPUs, and putting that CPU into another laptop of the same make and model fails to boot - they didn't lie about the chipset. And then TPM 2.0 and Microsoft pushing that onto everyone. Did you know Apple is working to ensure it's servers, shipped all over the world, are unassailable by people who have physical access to them? On it's own that's not weird, but then you remember Apple devices are specifically designed to be tamper-proof, encrypted, and unable to export the information on them. Put those two facts together, and suddenly you're not sure if Apple is trying to enslave it's users. So in summary, yes, I absolutely believe it's feasible to corrupt the majority of computers worldwide. It's why one of my desktops was *never* connected to Internet, and never will be. > With most of the platforms corrupted in a coordinated way we have > though not the original "trusting trust" problem but a much larger > one. One you have to solve if you want SSSBEA-CORDB and thus VSOBFS to take off. You should at the very least stop insisting VSOBFS is a silver bullet, and most of all, you should stop insinuating other people's efforts are wasteful and unnecessary (here I mean the comments regarding Michael's work). Various schemes to create a secure machine from scratch are in general immune to this problem. Yes, there are computers build with 7400 logic chips, and there are even computers build with discreet transistors. > Still, remaining hard copies of bootmedia of VSOBFS from before the > attack could serve as a safety anchor. The attack happened 15 years ago at the latest. It predates VSOBFS by a decade. > > On the other hand, the hex0 to tcc-0.9.26/janneke bootstrap is a > > fully verifiable source path. > > This is, sadly, not true. > > 1. hex0 is not a source, but the codes, exactly as they are to be > interpreted by the CPU. It is expected to be interpreted by the CPU, > right? At some point you need to be the binary interpreter. At the very least, you need to either assemble or disassemble the binary image. It's the only way. There is no other option. Bonus points for stamping the paper tape yourself. > But even if you have a reliable _disassembler_ behind your eyes, > how do you actually look at this binary code? As hex digits on a > screen? You could always output it onto a punch tape, print out the tape, verify the printout, then load the tape back into the computer. In addition, some people are able to read binary straight from the tape. It's not that difficult, thought I never actually looked at a tape, only ones and zeros on the screen. Also, you could always punch the tape as you're performing the assembly. > Some running binary blob must be involved to visualize the > contents of some file. Which is why, if you truly want information security, you need to start with the hardware. Strictly speaking, any and all x86 systems build after about 1988 or so, and all ARM systems, are to be assumed compromised. I don't know about RISC-V, but from what I know, it too is too big to be effectively audited, to include the audit of the IC under a microscope. Yes, we're looking under a microscope. Do you want security, or do you just want security theater and recognition for solving arbitrary logic problems with real-world implications? -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. --
signature.asc
Description: PGP signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
