'authorized-keys' field is badly documented

guix archive --authorize started issuing a warning some time ago

pointing to "authorized-keys" in "operating-system".

indicating what the syntax of the file is

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

raingloom <raingloom@riseup.net> writes:

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

in 10.8.1 Base Services.

--

Ricardo

On Sat, 16 Jan 2021 07:10:47 +0100

Ricardo Wurmus <rekado@elephly.net> wrote:

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.

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 :

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 :

Hi,

raingloom <raingloom@riseup.net> skribis:

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

retitle 45911 'authorized-keys' field is badly documented

quit

On Sat, 16 Jan 2021 22:24:16 -0500

Julien Lepiller <julien@lepiller.eu> wrote:

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?

Le 20 janvier 2021 15:34:11 GMT-05:00, raingloom <raingloom@riseup.net> a écrit :

Go ahead :)

On Wed, 20 Jan 2021 09:49:09 +0100

Ludovic Courtès <ludo@gnu.org> wrote:

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!

raingloom <raingloom@riseup.net> writes:

Use computed-file instead of local-file.

--

Ricardo

On Sat, 23 Jan 2021 10:10:15 +0100

Ricardo Wurmus <rekado@elephly.net> wrote:

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.

raingloom <raingloom@riseup.net> writes:

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