Debating Full Source Bootstrap

[Vagrant Cascadian]

On 2023-11-15, ahojlm at 0w.se wrote:
> On Tue, Nov 14, 2023 at 03:00:29PM -0800, Vagrant Cascadian wrote:
>> 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:
>> > 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.
>
> I appreciate your friendly tone and the occasion to discuss
> the topics related to reproducible builds and to VSOBFS.
>
> At the same time, it is hard to appreciate that you continue with
> persuasive definition of "dependency", superficially convenient to
> discredit the VSOBFS in the contended priority claim.

Can you build it without a preexisting C toolchain and running kernel?

To me, something required to build is a... dependency.

It is a bit disappointing to have something so straightforward and
presented in good faith be treated as anything else.


> I challenge you to explain how the use (of an arbitrary implementation)
> of a toolchain and of the other necessary tools affects the
> certainty of *source-only-based* provenance of the result in VSOBFS.

It certainly seems source-based, and it makes a strong correlation
between the source and the resulting artifacts by getting to a
bit-for-bit identical result from diverse paths.

Source only? Sure!
Verifyable so? Sure!
Full source? *shrug*

I also note, that presumably using a guix or live-bootstrap based
toolchain as one of the possible diverse implementations for VSOBFS,
makes an even stronger correlation. That is the beauty of diverse
implementations!

These projects can be used to make even stronger claims than any
individual project could alone.


>> > 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
>
> We do disagree on terms.
>
>> something like "Diversely Verifiable Bootstrap" based on the description.
...
> a redefinition of VSOBFS (which for a reason stands for *all* of
> "Verifiable Source Only Bootstrap") feels like a hostile move
> meant to undermine my priority position against Guix's offensive marketing.

I tried to incorporate my understanding and excitement of how VSOBFS
incorportates (elements of?) Diverse Double-Compiling into a
bootstrapping process and a way to simply describe that.

There was simply no hostility intended, apologies.


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/20231115/a40f02e3/attachment.sig>