[bug#36956] [PATCH] machine: Automatically authorize the coordinator's signing key.

[Ricardo Wurmus]

Christopher Lemmer Webber <address@hidden> writes:

> 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
>>> configurable.
>>>
>>> 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.
>>>
>>> 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? :)

It has the potential to break systems that are the target of “guix
deploy”.  The expected breakage would be minor as the acl can be
regenerated.

> 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.

I agree.

--
Ricardo