Debating Full Source Bootstrap

[Vagrant Cascadian]

On 2023-11-14, ahojlm at 0w.se wrote:
> 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.

Not quite full agreement, apparently. Just because you can freely
replace them does not mean to me that it is fully from source. It still
depends on arbitrary toolchains outside of the source. That kind of just
sounds like... bootstrapping.

Though... what is really exciting is VSOBFS has the excellent property
that you can replace the starter toolchain with some set of binaries;
this has many (all?) of the properties of Diverse Double-Compiling that
I was hoping would be incorporated in a bootstrap process! That is
truely, truely great!


>> 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.

This is really great, yes.


> 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.

Yes!


> 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.

These are great properties! But... not what I would call a full source
bootstrap. So perhaps we just disagree on terms. I would call VSOBFS
something like "Diversely Verifiable Bootstrap" based on the description.

I mean, most open source projects are built from source, with an
existing toolchain. The fact that VSOBFS builds the toolchain to build
the toolchain to build VSOBFS is part of a source based bootstrap
process... not quite what I would call a full source bootstrap.


>> 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.

I sincely doubt that will get changed at this point by reiterating the
same arguments, but you have definitely made your case, and I think the
arguments have been heard and understood by many of the people involved,
even if in the end some people choose to disagree.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20231114/fa29388d/attachment.sig>