'authorized-keys' field is badly documented

  • Open
  • quality assurance status badge
Details
4 participants
  • Julien Lepiller
  • Ludovic Courtès
  • raingloom
  • Ricardo Wurmus
Owner
unassigned
Submitted by
raingloom
Severity
normal
R
R
raingloom wrote on 16 Jan 2021 04:16
authorized-fields is not/badly documented
(name . Guix Bugs)(address . bug-guix@gnu.org)
20210116041615.27cfa112@riseup.net
guix archive --authorize started issuing a warning some time ago
pointing to "authorized-keys" in "operating-system".

* that is not a valid field of operating-system
* there is no such item in the Guix info page's index
* the relevant example loads a single key from a file, without
indicating what the syntax of the file is
* trying to store /etc/guix/signing-key.pub as a Scheme file results in
a parser error due to the hexadecimal syntax being incompatible with
some Scheme syntax weirdness

So, how the hecc do I add keys permanently the Official Way? Because I
have no idea. I'll try to update the docs when I figure it out.
OOoor... the person who introduced the change could document it. :|
R
R
Ricardo Wurmus wrote on 16 Jan 2021 07:10
(name . raingloom)(address . raingloom@riseup.net)
87o8hpbee0.fsf@elephly.net
raingloom <raingloom@riseup.net> writes:

Toggle quote (5 lines)
> guix archive --authorize started issuing a warning some time ago
> pointing to "authorized-keys" in "operating-system".
>
> * that is not a valid field of operating-system

That’s right. It’s a field of guix-configuration, which is documented
in 10.8.1 Base Services.

--
Ricardo
R
R
raingloom wrote on 17 Jan 2021 01:34
(name . Ricardo Wurmus)(address . rekado@elephly.net)
20210117013449.1192d841@riseup.net
On Sat, 16 Jan 2021 07:10:47 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

Toggle quote (11 lines)
> raingloom <raingloom@riseup.net> writes:
>
> > guix archive --authorize started issuing a warning some time ago
> > pointing to "authorized-keys" in "operating-system".
> >
> > * that is not a valid field of operating-system
>
> That’s right. It’s a field of guix-configuration, which is documented
> in 10.8.1 Base Services.
>

Thanks, I found that out already, that's how I ran into the other
issues.
I'm still confused about what the proper way to store the config info
is. Like how I should even store it as Scheme source code.
J
J
Julien Lepiller wrote on 17 Jan 2021 04:17
(address . 45911@debbugs.gnu.org)
936E2328-4662-4330-8BCA-50037B7CE3D7@lepiller.eu
I think you need to pass a file-like object, not a scheme expression. Don't try to modify or interpret the public key file, just pass it directly as-is.

Le 16 janvier 2021 19:34:49 GMT-05:00, raingloom <raingloom@riseup.net> a écrit :
Toggle quote (19 lines)
>On Sat, 16 Jan 2021 07:10:47 +0100
>Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> raingloom <raingloom@riseup.net> writes:
>>
>> > guix archive --authorize started issuing a warning some time ago
>> > pointing to "authorized-keys" in "operating-system".
>> >
>> > * that is not a valid field of operating-system
>>
>> That’s right. It’s a field of guix-configuration, which is
>documented
>> in 10.8.1 Base Services.
>>
>
>Thanks, I found that out already, that's how I ran into the other
>issues.
>I'm still confused about what the proper way to store the config info
>is. Like how I should even store it as Scheme source code.
Attachment: file
J
J
Julien Lepiller wrote on 17 Jan 2021 04:24
(address . 45911@debbugs.gnu.org)
08BFBF88-A677-47CE-9859-3B2FC33442F6@lepiller.eu

And the key file is the one generated by guix, unmodified: https://framagit.org/tyreunom/system-configuration/-/blob/master/keys/xana.pub

Le 16 janvier 2021 19:34:49 GMT-05:00, raingloom <raingloom@riseup.net> a écrit :
Toggle quote (19 lines)
>On Sat, 16 Jan 2021 07:10:47 +0100
>Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> raingloom <raingloom@riseup.net> writes:
>>
>> > guix archive --authorize started issuing a warning some time ago
>> > pointing to "authorized-keys" in "operating-system".
>> >
>> > * that is not a valid field of operating-system
>>
>> That’s right. It’s a field of guix-configuration, which is
>documented
>> in 10.8.1 Base Services.
>>
>
>Thanks, I found that out already, that's how I ran into the other
>issues.
>I'm still confused about what the proper way to store the config info
>is. Like how I should even store it as Scheme source code.
Attachment: file
L
L
L
Ludovic Courtès wrote on 20 Jan 2021 09:49
control message for bug #45911
(address . control@debbugs.gnu.org)
87k0s8f0x2.fsf@gnu.org
retitle 45911 'authorized-keys' field is badly documented
quit
R
R
raingloom wrote on 20 Jan 2021 21:34
Re: bug#45911: authorized-fields is not/badly documented
(name . Julien Lepiller)(address . julien@lepiller.eu)
20210120213411.3420d912@riseup.net
On Sat, 16 Jan 2021 22:24:16 -0500
Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (28 lines)
> Actually, here's how I use it:
> https://framagit.org/tyreunom/system-configuration/-/blob/master/systems/tachikoma.scm#L69
>
> And the key file is the one generated by guix, unmodified:
> https://framagit.org/tyreunom/system-configuration/-/blob/master/keys/xana.pub
>
> Le 16 janvier 2021 19:34:49 GMT-05:00, raingloom
> <raingloom@riseup.net> a écrit :
> >On Sat, 16 Jan 2021 07:10:47 +0100
> >Ricardo Wurmus <rekado@elephly.net> wrote:
> >
> >> raingloom <raingloom@riseup.net> writes:
> >>
> >> > guix archive --authorize started issuing a warning some time ago
> >> > pointing to "authorized-keys" in "operating-system".
> >> >
> >> > * that is not a valid field of operating-system
> >>
> >> That’s right. It’s a field of guix-configuration, which is
> >documented
> >> in 10.8.1 Base Services.
> >>
> >
> >Thanks, I found that out already, that's how I ran into the other
> >issues.
> >I'm still confused about what the proper way to store the config info
> >is. Like how I should even store it as Scheme source code.

Thanks, guess I'll go down the file route for now, but this is an
unsatisfactory solution IMHO.
What if you have multiple keys, or want to only include a subset of
keys in a given machine?
Having to use a file object to store a sexp is an odd choice when every
other part of Guix tries as hard as it can to use sexps and Scheme data
structures for configuration.

If no one wants to fix it, mind if I give it a go?
J
J
Julien Lepiller wrote on 20 Jan 2021 22:15
(name . raingloom)(address . raingloom@riseup.net)
A8B5F4CB-39B8-40B1-AC22-36B67ADFE27C@lepiller.eu
Le 20 janvier 2021 15:34:11 GMT-05:00, raingloom <raingloom@riseup.net> a écrit :
Toggle quote (44 lines)
>On Sat, 16 Jan 2021 22:24:16 -0500
>Julien Lepiller <julien@lepiller.eu> wrote:
>
>> Actually, here's how I use it:
>>
>https://framagit.org/tyreunom/system-configuration/-/blob/master/systems/tachikoma.scm#L69
>>
>> And the key file is the one generated by guix, unmodified:
>>
>https://framagit.org/tyreunom/system-configuration/-/blob/master/keys/xana.pub
>>
>> Le 16 janvier 2021 19:34:49 GMT-05:00, raingloom
>> <raingloom@riseup.net> a écrit :
>> >On Sat, 16 Jan 2021 07:10:47 +0100
>> >Ricardo Wurmus <rekado@elephly.net> wrote:
>> >
>> >> raingloom <raingloom@riseup.net> writes:
>> >>
>> >> > guix archive --authorize started issuing a warning some time ago
>> >> > pointing to "authorized-keys" in "operating-system".
>> >> >
>> >> > * that is not a valid field of operating-system
>> >>
>> >> That’s right. It’s a field of guix-configuration, which is
>> >documented
>> >> in 10.8.1 Base Services.
>> >>
>> >
>> >Thanks, I found that out already, that's how I ran into the other
>> >issues.
>> >I'm still confused about what the proper way to store the config
>info
>> >is. Like how I should even store it as Scheme source code.
>
>Thanks, guess I'll go down the file route for now, but this is an
>unsatisfactory solution IMHO.
>What if you have multiple keys, or want to only include a subset of
>keys in a given machine?
>Having to use a file object to store a sexp is an odd choice when every
>other part of Guix tries as hard as it can to use sexps and Scheme data
>structures for configuration.
>
>If no one wants to fix it, mind if I give it a go?

Go ahead :)
R
R
raingloom wrote on 23 Jan 2021 06:39
(name . Ludovic Courtès)(address . ludo@gnu.org)
20210123063903.66ad778c@riseup.net
On Wed, 20 Jan 2021 09:49:09 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (13 lines)
> Hi,
>
> raingloom <raingloom@riseup.net> skribis:
>
> > I'm still confused about what the proper way to store the config
> > info is. Like how I should even store it as Scheme source code.
>
> Did you see this section and do you find it helpful?
>
> https://guix.gnu.org/manual/en/html_node/Getting-Substitutes-from-Other-Servers.html
>
> Ludo’.

I have, that's how I found out where the setting even is.
An issue that I only now noticed is that it doesn't explain where to
obtain the signing key from, or the new behaviour of `guix archive
--authorize`.

If no one wants to fix it, I'll submit a patch once I'm done setting up
Snapper and some backups.

Edit after this sat in my queue for a few days:
Okay, so I figured out that I should use a G-Expression if I want to
compute the file, instead of just include it. Still not sure how to
store it as Scheme data, but I have an untested idea involving the
"pipe" syntax for symbols.

Thanks for the pointers!
R
R
Ricardo Wurmus wrote on 23 Jan 2021 10:10
(name . raingloom)(address . raingloom@riseup.net)
87y2gkj9xk.fsf@elephly.net
raingloom <raingloom@riseup.net> writes:

Toggle quote (5 lines)
> Okay, so I figured out that I should use a G-Expression if I want to
> compute the file, instead of just include it. Still not sure how to
> store it as Scheme data, but I have an untested idea involving the
> "pipe" syntax for symbols.

Use computed-file instead of local-file.

--
Ricardo
R
R
raingloom wrote on 25 Jan 2021 18:15
(name . Ricardo Wurmus)(address . rekado@elephly.net)
20210125181543.7f16e903@riseup.net
On Sat, 23 Jan 2021 10:10:15 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

Toggle quote (10 lines)
> raingloom <raingloom@riseup.net> writes:
>
> > Okay, so I figured out that I should use a G-Expression if I want to
> > compute the file, instead of just include it. Still not sure how to
> > store it as Scheme data, but I have an untested idea involving the
> > "pipe" syntax for symbols.
>
> Use computed-file instead of local-file.
>

I know about computed-file, the issue is that the syntax of the key is
not strictly Scheme. The long hexadecimal block isn't parsed as a
number:
```
(with-input-from-file "/etc/guix/signing-key.pub" read)
...
/etc/guix/signing-key.pub:4:8: Unknown # object: #\C
```

Trying to store it as a module results in the same error.
So I can't just have an associative list of hostnames and signing keys
and filter it based on the hostname, I have to store each key as an
opaque file, completely bypassing the module system.
R
R
Ricardo Wurmus wrote on 26 Jan 2021 08:13
(name . raingloom)(address . raingloom@riseup.net)
877do0jhld.fsf@elephly.net
raingloom <raingloom@riseup.net> writes:

Toggle quote (22 lines)
> On Sat, 23 Jan 2021 10:10:15 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> raingloom <raingloom@riseup.net> writes:
>>
>> > Okay, so I figured out that I should use a G-Expression if I want to
>> > compute the file, instead of just include it. Still not sure how to
>> > store it as Scheme data, but I have an untested idea involving the
>> > "pipe" syntax for symbols.
>>
>> Use computed-file instead of local-file.
>>
>
> I know about computed-file, the issue is that the syntax of the key is
> not strictly Scheme. The long hexadecimal block isn't parsed as a
> number:
> ```
> (with-input-from-file "/etc/guix/signing-key.pub" read)
> ...
> /etc/guix/signing-key.pub:4:8: Unknown # object: #\C
> ```

These are canonical s-expressions. You can read them with
“read-file-sexp” from (gcrypt pk-crypto). Or you can convert them to
readable s-expressions with “canonical-sexp->sexp”. Or you can create
them from strings with “string->canonical-sexp”.

--
Ricardo
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 45911@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 45911
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch