From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4JxiOTrF2F7aaAAA0tVLHw (envelope-from ) for ; Thu, 04 Jun 2020 09:56:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sGAyNTrF2F79IgAA1q6Kng (envelope-from ) for ; Thu, 04 Jun 2020 09:56:10 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7272F9401AE for ; Thu, 4 Jun 2020 09:56:09 +0000 (UTC) Received: from localhost ([::1]:39490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgmbY-0005bL-De for larch@yhetil.org; Thu, 04 Jun 2020 05:56:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgmbR-0005b8-VI for bug-guix@gnu.org; Thu, 04 Jun 2020 05:56:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgmbR-0006f8-Ma for bug-guix@gnu.org; Thu, 04 Jun 2020 05:56:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jgmbR-0004FT-LW; Thu, 04 Jun 2020 05:56:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#22883: Channel introductions Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 04 Jun 2020 09:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22883 X-GNU-PR-Package: guix X-GNU-PR-Keywords: security To: zimoun Received: via spool by 22883-submit@debbugs.gnu.org id=B22883.159126451416275 (code B ref 22883); Thu, 04 Jun 2020 09:56:01 +0000 Received: (at 22883) by debbugs.gnu.org; 4 Jun 2020 09:55:14 +0000 Received: from localhost ([127.0.0.1]:45172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgmaf-0004EQ-GA for submit@debbugs.gnu.org; Thu, 04 Jun 2020 05:55:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgmad-0004EE-Jw for 22883@debbugs.gnu.org; Thu, 04 Jun 2020 05:55:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57647) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgmaY-00068Y-9I; Thu, 04 Jun 2020 05:55:06 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=44756 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jgmaW-0003mS-Er; Thu, 04 Jun 2020 05:55:04 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87wpket748.fsf@gnu.org> <87bmkwm8ed.fsf@gnu.org> <87png9o8i2.fsf@elephly.net> <87fth4bj6y.fsf@gnu.org> <87bln9oupo.fsf@gnu.org> <87wo5vfuxi.fsf@gnu.org> <87o8qjekt7.fsf@gnu.org> <87v9kanalz.fsf_-_@gnu.org> <875zc8pjfu.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 Prairial an 228 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 04 Jun 2020 11:55:02 +0200 In-Reply-To: (zimoun's message of "Wed, 3 Jun 2020 18:20:32 +0200") Message-ID: <87lfl3dukp.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -3.3 (---) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 22883@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: 0.49 X-TUID: 6sk1Kf0VLE+J Hi, zimoun skribis: > On Wed, 3 Jun 2020 at 11:50, Ludovic Court=C3=A8s wrote: >> zimoun skribis: >> > On Mon, 1 Jun 2020 at 16:08, Ludovic Court=C3=A8s wrote: > >> >> If that information were stored in =E2=80=98.guix-channel=E2=80= =99, it would be >> >> trivial for an attacker to fork the project (or push a new commi= t) >> >> and pretend the authentication process must not take previous >> >> commits into account. >> > >> > What will happen to recursive '.guix-channel'? The '.guix-channel' of >> > channel A contains the reference to the channel B where the >> > '.guix-channel' contains the reference to the channel C, etc. >> >> I=E2=80=99m not sure I understand. (The sentence above is about *not* s= toring >> info in =E2=80=98.guix-channel=E2=80=99.) > > Sorry, I have misread. > The question about recursive still applies. ;-) > Currently, if the local channel file points to a channel A which > contains the file '.guix-channel' which points to another channel B, > then when one runs "guix pull" well the channel A will be pulled and > then the channel B, even if this channel B is not explicit in the > initial local channel. (Even, there is bug about recursive implicit > pulls, see http://issues.guix.gnu.org/issue/41069; well another > story.) > > What happens for such situation? Nothing special, I guess: each channel would be authenticated (or not, if it=E2=80=99s an unsigned channel). I think it=E2=80=99s completely orth= ogonal. >> >> 4. When publishing a fork of a channel, one emits a new channel >> >> introduction. Users switching to the fork have to explicitly al= low >> >> that new channel via its introduction; flipping the URL won=E2= =80=99t be >> >> enough because =E2=80=98guix pull=E2=80=99 would report unauthor= ized commits. >> > >> > I am a bit afraid by this... and I hope that a fork of a channel will >> > still work without emitting a new channel introduction. >> >> No, when publishing a fork of an authenticated channel, you=E2=80=99ll h= ave to >> publish its introduction alongside its URL. > > I do not understand your two answers. Well, there is 4 situations > when publishing: > > 1- an authenticated fork of an authenticated channel > 2- an authenticated fork of an unauthenticated channel > 3- an unauthenticated fork of an authenticated channel > 4- an unauthenticated fork of an unauthenticated channel > > "authenticated channel" means a channel using all the authentication mach= inery. > "authenticated fork" means add a "channel introduction" and so become > a "authenticate channel" then. I=E2=80=99m sorry, I don=E2=80=99t follow the terminology. > Today, we are in the situation 4. and we are going to the 1. if I > understand correctly. > And if I understand your answer above about good ol' channel, the 4. > will still work and emit a warning, isn't it? > What about the 2. and 3.? > > These situations correspond to: > > 1- the correct way > 2- bootstrap the trust > 3- and 4- quick and dirty "Scientific" workflows where the security is > not a concern. Funny how =E2=80=9Cscientific=E2=80=9D has become synonymous with =E2=80=9C= quick-and-dirty=E2=80=9D these days=E2=80=A6 [=E2=80=A6] > Genuine commits and outdated mirrors are separated questions, IMHO. > > >> Since there=E2=80=99s no way to answer the question =E2=80=9Cis this the= latest commit?=E2=80=9D >> in a general way, the best we can do, I think, is to detect whether >> we=E2=80=99re talking to the =E2=80=9Cofficial=E2=80=9D Git repo. > > What does "official" mean here? To me, it means commits that I trust, > i.e., approved by an authority. My local clone is not less "official" > than the repo on Savannah. > > I do not understand why the question =E2=80=9Cis this the latest commit?= =E2=80=9D has > to be answered. If an user wants the latest commits, then they > directly pulls from upstream, i.e, from Savannah. If an user wants to > pull from a mirror for whatever reasons, then they knows that the last > updates are not necessary there, since it is a mirror and not upstream > -- and it is the responsibility of the mirror maintainer to keep it > up-to-date. However, what the user wants to know is whether the > mirror has not introduced malicious commits. Guix is a software supply tool. There are two important security questions a software supply client must address: =E2=80=9Cam I getting the authentic stuff?=E2=80=9D, and =E2=80=9Cam I getting the latest stuff?=E2= =80=9D. The first one is obvious, the second one relates to =E2=80=9Cdowngrade attacks=E2=80=9D w= hich can introduce known security vulnerabilities. Things like The Update Framework (TUF) address both, but they do that in a context that=E2=80=99s technically =E2=80=9Clike Debian=E2=80=9D (binary = distro) and very different from Guix. Yet, these two issues must also be addressed in Guix, like in any other distro. What we=E2=80=99ve been discussing here addresses the first question. For = the second question, the best answer I came up with is that of an =E2=80=9Coffi= cial URL=E2=80=9D, allowing users to know the URL that should give them the late= st stuff. =E2=80=9COfficial=E2=80=9D means that it genuinely comes from the organizat= ion I entrusted with my computer, be it the Guix project, another organization maintaining a Guix fork, or an organization maintaining a Guix channel. I hope that makes sense. Thanks, Ludo=E2=80=99.