From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:38436) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hy0FX-000323-Na for guix-patches@gnu.org; Wed, 14 Aug 2019 16:52:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hy0FW-0004HY-KL for guix-patches@gnu.org; Wed, 14 Aug 2019 16:52:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:40967) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hy0FW-0004HK-HB for guix-patches@gnu.org; Wed, 14 Aug 2019 16:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hy0FW-0000hz-Db for guix-patches@gnu.org; Wed, 14 Aug 2019 16:52:02 -0400 Subject: [bug#36956] [PATCH] machine: Automatically authorize the coordinator's signing key. Resent-Message-ID: References: <87ef1x4015.fsf@sdf.lonestar.org> <874l2sydbs.fsf@elephly.net> <87zhkkk8a6.fsf@sdf.lonestar.org> <87ftmanxol.fsf@sdf.lonestar.org> From: Christopher Lemmer Webber In-reply-to: <87ftmanxol.fsf@sdf.lonestar.org> Date: Wed, 14 Aug 2019 16:51:24 -0400 Message-ID: <87imqzxygj.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: "Jakob L. Kreuze" Cc: 36956@debbugs.gnu.org Jakob L. Kreuze writes: > zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes: > >> Hi Chris and Ricardo, >> >> Christopher Lemmer Webber writes: >> >>> This seems like a good usability improvement. For clarity, I assume >>> that it's still configurable, however? Would be important if pushing >>> builds to a different machine. >> >> No, but you raise a good point :) I'll update this patch to make it >> configurable. >> >> Ricardo Wurmus writes: >> >>> This will overwrite an existing acl file on the remote with a copy >>> that differs only in the newly added key. >>> >>> Is there a chance for corruption, e.g. if acl->public-keys returns >>> something unexpected? >> >> I suppose it's possible. 'guix archive --authorize' doesn't seem to do >> any specific handling for it, but it doesn't hurt to be paranoid -- we >> "atomically" overwrite the GC root for the bootloader configuration, for >> example, and we could do something similar here. I'll include it in the >> updated patch. >> >> Regards, >> Jakob >> > > I didn't think this all the way through when I wrote this response. > We're already using 'with-atomic-file-output', so we're already > "atomically" overwriting the ACL. Also, it wouldn't solve the issue of > 'acl->public-keys' returning something unexpected. > > I'm not sure I have a good solution for this at the moment. But it's only a problem for guix deploy so far, right? So it shouldn't break existing, hopefully-stable guix systems and rather only bleeding-edge guix deploy systems, right? :) If that's true then let's file a bug about this issue and get this code merged after you get this in patch series form.