[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36956] [PATCH] machine: Automatically authorize the coordinator's s
From: |
Jakob L. Kreuze |
Subject: |
[bug#36956] [PATCH] machine: Automatically authorize the coordinator's signing key. |
Date: |
Fri, 09 Aug 2019 11:52:26 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
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.
Regards,
Jakob
signature.asc
Description: PGP signature