From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: GNU Guix Questions Date: Tue, 07 Mar 2017 14:57:54 +0100 Message-ID: <87k281chp9.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clFcq-00077k-Ii for guix-devel@gnu.org; Tue, 07 Mar 2017 08:58:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clFcp-0002Ev-Oe for guix-devel@gnu.org; Tue, 07 Mar 2017 08:58:04 -0500 In-Reply-To: (bancfc@openmailbox.org's message of "Mon, 06 Mar 2017 16:14:08 +0100") 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: bancfc@openmailbox.org Cc: guix-devel@gnu.org, whonix-devel@whonix.org Hi! bancfc@openmailbox.org skribis: > * Does Guix defend against the variety of attacks described in the TUF > threat model document? (described in link below) How resilient is it > against key compromise? (TUF was designed from the ground up to > provide a highly resilient and secure update framework as a drop in > replacement to crappy standalone updaters - a problem that's become > very serious for proprietary OSes. The security research and > implementation behind it are an excellent rubric that one can apply to > any updater/package manager.) > > https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md The short answer is: not yet. The longer answer is that TUF is biased towards =E2=80=9Ctraditional=E2=80= =9D package managers where the main asset is a binary package archive. Guix is conceptually a source-based package manager, so what we want to authenticate is Git checkouts of Guix itself. TUF needs to be =E2=80=9Cpor= ted=E2=80=9D to this model. We=E2=80=99ll address this hopefully within a few months, a= nd definitely by 1.0: https://bugs.gnu.org/22883 Ludo=E2=80=99.