From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Preparing the reduced bootstrap tarballs Date: Sun, 18 Nov 2018 13:27:30 -0500 Message-ID: <8736ryutoy.fsf@netris.org> References: <87a7m61r4m.fsf@ITSx01.pdp10.guru> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gORnw-0001Ry-9H for guix-devel@gnu.org; Sun, 18 Nov 2018 13:28:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gORnt-00067p-2V for guix-devel@gnu.org; Sun, 18 Nov 2018 13:28:20 -0500 Received: from world.peace.net ([64.112.178.59]:54938) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gORns-00067b-Vf for guix-devel@gnu.org; Sun, 18 Nov 2018 13:28:17 -0500 In-Reply-To: <87a7m61r4m.fsf@ITSx01.pdp10.guru> (Jeremiah's message of "Sun, 18 Nov 2018 12:56:09 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jeremiah@pdp10.guru Cc: guix-devel@gnu.org Hi, Jeremiah@pdp10.guru 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