[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36956] [PATCH] machine: Automatically authorize the coordinator's s
Christopher Lemmer Webber
[bug#36956] [PATCH] machine: Automatically authorize the coordinator's signing key.
Wed, 14 Aug 2019 16:51:24 -0400
mu4e 1.2.0; emacs 26.2
Jakob L. Kreuze writes:
> address@hidden (Jakob L. Kreuze) writes:
>> Hi Chris and Ricardo,
>> Christopher Lemmer Webber <address@hidden> 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
>> Ricardo Wurmus <address@hidden> 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.
> 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.