Debating Full Source Bootstrap

[ahojlm at 0w.se]

On Tue, Nov 14, 2023 at 10:18:01AM -0800, Vagrant Cascadian wrote:
> On 2023-11-14, ahojlm at 0w.se wrote:
> > On Sun, Nov 12, 2023 at 06:19:31PM -0800, Vagrant Cascadian wrote:
> >> The very thing the "Full-Source Bootstrap" builds is a C development
> >> toolchain; that is arguably the whole point of the "Full-Source
> >> Bootstrap" ... to avoid starting with a C development toolchain, by
> >> starting from source, and building up to a working C toolchain...
> >
> > Before addressing in detail, TL;DR:
> > The above looks regrettably like a persuasive definition[1].
> ...
> > [1] "a form of stipulative definition which purports to describe the true
> >     or commonly accepted meaning of a term, while in reality stipulating
> >     an uncommon or altered use, usually to support an argument for some view"
> >     https://en.wikipedia.org/wiki/Persuasive_definition
> 
> I dispute the use of "altered or uncommon". Starting with a prebuilt C
> compiler and claiming to bootstrap from source is a far more altered or
> uncommon meaning for "Full Source Bootstrap" to me than bootstrapping
> from an auditable hex binary.

> > Why would "full-source" mean something other than
> > that dependencies on anything but source are excluded?
> 
> I aboslutely agree with you here! Which is why I am so confused by this
> whole argument!

Then we are in full agreement.
The result of VSOBFS does not depend on the host binaries used in
the process. You can freely replace them with ones of your choice,
as long as those are functional at all.

> I don't understand why you are arguing that something that depends on a
> prebuilt existing C compiler toolchain to be a full source bootstrap.

You think probably about dependencies on the *contents* of a binary,
in other words, on a certain *implementation* of some functionality,
be it a compiler or a copy program.

VSOBFS postulates multiple, diverse, unrelated bootstraps which makes
any faulty corresponding implementation to produce a diversion, while
sane host systems all yield the same result.

The sanity indication is reliable to any desirable degree, by adding
the diversity and choosing host systems which in practical terms are
least vulnerable to possible coordinated attacks.

Moreover, some of this work (to bootstrap on diverse and protected
systems) has already been done by yours truly. VSOBFS itself consists
only of source code and you can easily test that the result of your
VSOBFS-bootstrap corresponds to the announced one. Then you can be
sure about the source provenance of the resulting OS, regardless which
hard- and software you have used.

> If pushed, and there does feel to be a bit of pushing going on, I think
> I would argue that neither Guix nor VSOBFS are yet technically "Full
> Source Bootstraps", as they depend on pre-existing binaries (kernel and
> C compiler in one case, kernel and guile binary in another).

Even from this point of view (which I do not agree with, as argued above)
the phrase
"something that had never been achieved, to our knowledge, since the
birth of Unix"
does not belong there in the Guix blog which started the controversy.

This is what I kindly ask to correct.

Regards,
 an