Dear Michael, I unfortunately feel unsettled by your promotion of bootstrappable.org and of the Mes project on this list.
TL;DR tinycc as-is is good enough for complete and reproducible bootstrapping, thanks to the presence of its historical versions. This is proven by VSOBFS[1] which has fully solved the "trusting trust problem", in contrast to the projects mentioned above. On Tue, Jun 02, 2026 at 09:15:15AM +0000, Michael Ackermann via Tinycc-devel wrote: > Currently, you may have a look at live-bootstrap project from > bootstrappable.org I dare to say that the marketing of the projects you refer to is extremely misleading. Please read on a bit, take a note of the wording [0] ==================================================================== "The Full-Source Bootstrap: Building from source all the way down" ------------------------------------------------------------------ "22,000 nodes rooted in a 357-byte program—something that had never been achieved, to our knowledge, since the birth of Unix." This sounds impressive, new and groundbreaking? But wait, to build 22000 interrelated packages from source has been done by other projects earlier, what is new? A reliance on a 375-byte binary program? Most of all, why is it actually called "full source"? Moreover, later down in the same text you read "the set of binaries from which packages are built includes a 25 MiB statically-linked Guile" This is _not_ "357 byte". What does "full" mean in the above so called "full source" "all the way"? I asked and insisted, got no answer. ==================================================================== That kind of bootstrapping does not[2] provide any real guarantees of avoiding trust in binaries (to avoid the trust is the stated goal of bootstrapping). To be useful, the above actually needs an addition of multiple-diverse-compilation. Ironically, the latter suffices all-by-itself, as shown by VSOBFS[1]. What Mes and bootstrappable.org are doing is neither sufficient[2] to avoid trust-in-binaries, nor necessary for this purpose[1]. ==== That's why pointing to their needs as a reference for tinycc ==== bothers your humble servant. NLnet has spent money (not least EU money) on Mes, seems to spend money on "live-bootstrap", for pseudo-solving a fully solved problem. Remarkably, an NLnet representative, when I asked, believed that the binary seed in Mes was optional :) this is what happens when people do not read the fine print? Full disclosure: I am the author of the actual solution, VSOBFS, published in March 2023. It provides a guarantee that the binary output is fully defined by the sources and _nothing_else_. This work did not cost anything for the society and the result is in the public domain. 1. The VSOBFS work would be much harder without tinycc, thanks a lot! 2. tinycc as-is is good enough for complete and reproducible bootstrapping, thanks to the presence of its historical versions. This is proven by VSOBFS. Best regards tccm [0] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ April 26, 2023, compare to the date of VSOBFS announcement March 8, 2023 [1] https://codeberg.org/keciav/vsobfs [2] besides the "seed" itself you need binaries to examine it, even to be able to put it in memory for execution _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
