Re: Preparing the reduced bootstrap tarballs

[Mark H Weaver]

Hi,

address@hidden writes:

>> However, my impression (correct me if I'm wrong) is that we are not yet
>> able to bootstrap Guix exclusively from M2-Planet.
> That is correct as the step of bootstrapping MesCC from M2-Planet is not
> yet complete.
> However once that is done, we can leverage Mes.c and gash to complete
> the bootstrap of guix from that trusted reproducible source in a
> reproducible fashion.
>
>> For example, unless
>> I'm mistaken, we still need Guile in our bootstrap, and I'm guessing
>> that we are not yet able to build Guile exclusively from M2-Planet.
>> Is that right?
> We don't need it, so much as it is people wishing to avoid tedious work.
> We already can bootstrap kaem without any shells or interpreters and it
> can be used to run shell scripts that can perform the rest of the
> bootstrap of a lisp or a proper shell.
>
> I think because that work is less of a technical challenge that it has
> been skipped.

I get the feeling that we are talking about two different things here.
I'm not saying that Guile is needed to bootstrap a GNU system from
source by hand.

When I say "we still need Guile in our bootstrap", I'm referring
specifically to the Guix "bootstrap binaries".  Guix uses Guile to
execute its automated build scripts.

Anyway, I've answered my own question by looking at:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?h=core-updates-next&id=d9ed0a46301e259c3082fcc67678e72ceae19a2d#n778

which indicates to me that although gcc, binutils, and glibc have been
eliminated from the Guix bootstrap binaries, they still include
statically-linked versions of Guile, Coreutils, Bzip2, XZ, Gawk, Tar,
and Grep.  These are the remaining precompiled binaries that I'm worried
about.

>> I have higher confidence in our 2013 binaries than
>> in binaries we would produce today, because (1) we are more likely to be
>> a target today because Guix has become far more popular, (2) I expect
>> that intelligence agencies have far more advanced tools today than they
>> did in 2013, and (3) I expect that governmental policies have become far
>> more favorable to permitting such attacks against projects such as ours.
>
> 1) Granted
> 2) Not exactly; simply because the most advanced attack tool ever
> invented was the Nexus Intruder Program in 1958. (Hardware that subverts
> software that later subverts hardware designs and more software
> [firmware, microcode, etc]). The tools might get more expensive but the
> actual quality of attack tools depends on the teams and the market's
> demand for pumping out vulnerable products and bugs. (Like the recent
> Hard drive firmware attack which leveraged the vendor's cost cutting
> process to hijack the drives and then lock out future attempts at
> recovery.

Interesting.  I didn't know about the Nexus Intruder Program, but even
so, I don't think this invalidates my point (2).

> 3) Actually Government agencies are depending more and more on "Open
> source tools" (Their words not mine) as software budgets have gotten
> tighter and third party vendors integrate them more and more into their
> commercial offerings purchased by Goverment agencies. Putting a backdoor
> in the software most Government agencies depend upon, invites
> vulnerabilities in our own Intelligence Agencies infrastructure and
> increase the probablity that Spies will be identified before their
> flight to their target country leaves the ground. To do such would not
> only be suicidal for those Intelligence Agencies but also ensure
> Cyberwarfare against the Countries they work for that much more
> effective.
>
> Now that isn't to say they consider that an extranality and doom us all

Right.  It is by now well accepted fact that the NSA has deliberately
weakened cryptographic standards, for example, and your argument above
would seem to argue against the truth of that fact as well.

> but nothing stays hidden when we can read the source and can DDC our
> entire bootstrap across arbitrary hardware/operating system
> combinations.

Here I disagree.  DDC is a crucially important step, but even after we
have DDC, a large number of security flaws will continue to stay hidden
in our code.  We have far too much code to audit, and too much of it
written in C, which makes it quite difficult to write secure code.
Common classes of security bugs in C such as signed integer overflows
and other undefined behavior can be very hard to find, and I have little
confidence that all of these bugs would be found in any practical audit.

Moreover, our current development practices ensure that new bugs of this
kind will be continuously reintroduced into our software, even as we
discover and fix many of the existing bugs.

So, your work is a very important part, but not a complete solution to
the problem of building a computer system that we can truly consider
trustworthy.

     Regards,
       Mark