bug#45911: authorized-fields is not/badly documented

bug#45911: authorized-fields is not/badly documented

[raingloom]

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

bug#45911: authorized-fields is not/badly documented

[Ricardo Wurmus]

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.

-- 
Ricardo

bug#45911: authorized-fields is not/badly documented

[raingloom]

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.

bug#45911: authorized-fields is not/badly documented

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

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 :
>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 #2: Type: text/html, Size: 1427 bytes --]

bug#45911: authorized-fields is not/badly documented

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1739 bytes --]

bug#45911: authorized-fields is not/badly documented

[raingloom]

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?

bug#45911: authorized-fields is not/badly documented

[Julien Lepiller]

Le 20 janvier 2021 15:34:11 GMT-05:00, raingloom <raingloom@riseup.net> a écrit :
>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 :)

bug#45911: authorized-fields is not/badly documented

[Ludovic Courtès]

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

bug#45911: authorized-fields is not/badly documented

[raingloom]

On Wed, 20 Jan 2021 09:49:09 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

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

bug#45911: authorized-fields is not/badly documented

[Ricardo Wurmus]

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.

-- 
Ricardo

bug#45911: authorized-fields is not/badly documented

[raingloom]

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

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.

bug#45911: authorized-fields is not/badly documented

[Ricardo Wurmus]

raingloom <raingloom@riseup.net> writes:

> 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