Hello Ivo, On Mon, Jul 13, 2026 at 02:18:14PM +0200, Ivo van Poorten wrote: > On Mon, 13 Jul 2026 11:34:04 +0200 [email protected] wrote: > > On Sun, Jul 12, 2026 at 09:21:09PM +0200, Aleksandar Kuktin wrote: > > > But the same outcome can happen in one other situation: if all the > > [... skipped ...] > > > not of equally-dishonest builders. > > > > I appreciate your willingness to analyze the possible problems in > > depth. > > > > I am though pretty unsure whether such a discussion is on-topic here. > > [3] > > It's off-topic, but I'm interested.
Thanks for the interest. (I mark also the thread as offtopic) > You skipped reacting to the last section of Aleksandar's post. Aleksandar could not access the information on the web site before posting and I did not see a point in reacting to guesses. > What happens if your compilation fleet > disagrees? It seems to me that "assume the majority is right" is not > enough. The majority could be compromised. 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. With most of the platforms corrupted in a coordinated way we have though not the original "trusting trust" problem but a much larger one. Still, remaining hard copies of bootmedia of VSOBFS from before the attack could serve as a safety anchor. Now, to clarify the assumptions needed for a complete positive assurance let me cite the "Limits of verifiability" text: "If we e.g. would choose to take for granted that *specifically corrupted*[*] installations represent at maximum a *minority* in the chosen installations pool and at the same time we observe a majority consensus, then the integrity assertion could be said to be *"complete"*" [*] in short: the ones producing a bad disk image but faking a checksum to match the good one This looks to me like a pretty reasonable assumption. > 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? The comments are irrelevant for verification, they are not the code. 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? Some running binary blob must be involved to visualize the contents of some file. You can not examine the file without a preexisting viewer binary. You need other running binaries to put the code onto boot media as well. If you mean that hex0 "verifiability" would exclude the "trusting trust" problem, such a setup does not do it. A corrupt system used for the boot preparation is fully capable of subverting the result. You must either trust the preparing system and the firmware of the "bootstrapped" one or rely on multiple diverse reproducible bootstrapping for verification of the results. Then what was the point, besides the "hack value", of using the chain from the machine code to intermediate stages to C99, when you can as well and safely begin from C99? Kind regards /tccm _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
