From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 01 08:18:02 2020 Received: (at 42048) by debbugs.gnu.org; 1 Jul 2020 12:18:02 +0000 Received: from localhost ([127.0.0.1]:52479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jqbgf-0008Cc-Vz for submit@debbugs.gnu.org; Wed, 01 Jul 2020 08:18:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jqbgd-0008CB-Aj for 42048@debbugs.gnu.org; Wed, 01 Jul 2020 08:18:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38253) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqbgX-0006gV-TH; Wed, 01 Jul 2020 08:17:53 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=53972 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jqbgW-0004yV-FQ; Wed, 01 Jul 2020 08:17:53 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: zimoun Subject: Re: [bug#42048] [PATCH 0/6] Authenticated channels for everyone! References: <20200625210400.29033-1-ludo@gnu.org> <86ftaba874.fsf@gmail.com> Date: Wed, 01 Jul 2020 14:17:50 +0200 In-Reply-To: <86ftaba874.fsf@gmail.com> (zimoun's message of "Wed, 01 Jul 2020 11:35:59 +0200") Message-ID: <87a70jzaxd.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-Debbugs-Envelope-To: 42048 Cc: 42048@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, zimoun skribis: > On Thu, 25 Jun 2020 at 23:04, Ludovic Court=C3=A8s wrote: > >> The most visible effect is that channel introductions are now >> part of the API and shown by =E2=80=98guix describe=E2=80=99. It become= s a long-term >> commitment because we want to be able to pass the output of >> =E2=80=98guix describe -C channels=E2=80=99 or /run/current-system/chann= els.scm >> to =E2=80=98guix pull=E2=80=99 and =E2=80=98guix time-machine=E2=80=99 i= n the future. > > How could I test this machinery with "guix time-machine"? The normal way. :-) But of course, the new =E2=80=98introduction=E2=80=99 field of wo= n=E2=80=99t be recognized by older Guix versions. In that case, you should use the output of =E2=80=98guix describe -f channels-sans-intro=E2=80=99 as I wrote= in the manual. >> Contrary to what I initially proposed=C2=B9, channel introductions are >> stripped to the bare minimum: a commit/fingerprint pair (as is >> currently the case on master, internally). I figured it doesn=E2=80=99t >> buy us much to have the commit/fingerprint pair signed; what >> matters is that users obtain the introduction from a trusted >> source, and the signature wouldn=E2=80=99t help with that. I also got >> rid of the idea of rendering introductions are opaque base64 blobs. > > What happens when traveling in time if the key used by the signature has > been compromised? In general, when a developer loses control over their key, another committer should remove it right away form =E2=80=98.guix-authorizations=E2= =80=99. (I did that today following Brett=E2=80=99s message, for example.) Signatures on past commits can still be verified and everything is fine. The (guix openpgp) code ignores key expiration and revocation; it =E2=80=9C= just=E2=80=9D verifies signatures. > Today, everything is fine, I sign and I do in introduction. Couple of > months (or even years) later, my key will be compromised and so I will > revoke it. What happens if I do "guix time-machine -C"? That=E2=80=99s OK. The keyring is distributed along with the channel still contains your key, with or without a revocation certificate, but that doesn=E2=80=99t prevent us from verifying signatures on past commits. (Thi= s is different from what gpg does.) Ludo=E2=80=99.