* Using G-Expressions for public keys (substitutes and possibly more) @ 2021-10-17 12:47 Liliana Marie Prikler 2021-10-21 20:13 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Liliana Marie Prikler @ 2021-10-17 12:47 UTC (permalink / raw) To: guix-devel Hi Guix, let's say I wanted to add my own substitute server to my config.scm. At the time of writing, I would have to add said server's public key to the authorized-keys of my guix-configuration like so: (cons* (local-file "my-key.pub") %default-authorized-guix-keys) or similarily with append. This local-file incantation is however pretty weak. It changes based on the current working directory and even if I were to use an absolute path, I'd have to copy both that file and the config.scm to a new machine were I to use the same configuration there as well. However, it turns out that the format for said key files is some actually pretty readable Lisp-esque stuff. For instance, an ECC key reads like (public-key (ecc (curve CURVE) (q #Q#))) with spaces omitted for simplicity. Were it not for the (q #Q#) bit, we could construct it using scheme- file. In fact, it is so simple that in my local config I now do exactly that. (define-record-type* <ecc-key> ...) (define-gexp-compiler (ecc-key-compiler (ecc-key <ecc-key>) ...) ...) (ecc-key (name "my-key.pub") (curve 'Ed25519) (q "ABCDE...")) Could/should we support such formats out of the box? WDYT? Regards, Liliana ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-10-17 12:47 Using G-Expressions for public keys (substitutes and possibly more) Liliana Marie Prikler @ 2021-10-21 20:13 ` Ludovic Courtès 2021-10-22 4:47 ` Liliana Marie Prikler 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2021-10-21 20:13 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: guix-devel Hi! Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > let's say I wanted to add my own substitute server to my config.scm. > At the time of writing, I would have to add said server's public key to > the authorized-keys of my guix-configuration like so: > (cons* (local-file "my-key.pub") %default-authorized-guix-keys) > or similarily with append. This local-file incantation is however > pretty weak. It changes based on the current working directory and > even if I were to use an absolute path, I'd have to copy both that file > and the config.scm to a new machine were I to use the same > configuration there as well. Note that you could use ‘plain-file’ instead of ‘local-file’ and inline the key canonical sexp in there. > However, it turns out that the format for said key files is some > actually pretty readable Lisp-esque stuff. For instance, an ECC key > reads like > (public-key (ecc (curve CURVE) (q #Q#))) > with spaces omitted for simplicity. > Were it not for the (q #Q#) bit, we could construct it using scheme- > file. In fact, it is so simple that in my local config I now do > exactly that. Yeah it’s frustrating that canonical sexps are almost, but not quite, Scheme sexps. :-) (gcrypt pk-crypto) has a ‘canonical-sexp->sexp’ procedure: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> ,use(gcrypt pk-crypto) scheme@(guile-user)> ,use(rnrs io ports) scheme@(guile-user)> (string->canonical-sexp (call-with-input-file "etc/substitutes/ci.guix.info.pub" get-string-all)) $18 = #<canonical-sexp 7fce7f4e8b40 | 15d96a0> scheme@(guile-user)> ,pp (canonical-sexp->sexp $18) $19 = (public-key (ecc (curve Ed25519) (q #vu8(141 21 111 41 93 36 176 217 168 111 165 116 26 132 15 242 210 79 96 247 182 196 19 72 20 173 85 98 89 113 179 148)))) --8<---------------cut here---------------end--------------->8--- > (define-record-type* <ecc-key> ...) > (define-gexp-compiler (ecc-key-compiler (ecc-key <ecc-key>) ...) ...) > > (ecc-key > (name "my-key.pub") > (curve 'Ed25519) > (q "ABCDE...")) > > Could/should we support such formats out of the box? WDYT? With this approach, we’d end up mirroring all the canonical sexps used by libgcrypt, which doesn’t sound great from a maintenance POV. Would providing an example in the doc that uses ‘canonical-sexp->sexp’ and its dual help? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-10-21 20:13 ` Ludovic Courtès @ 2021-10-22 4:47 ` Liliana Marie Prikler 2021-11-21 0:12 ` Jelle Licht 0 siblings, 1 reply; 9+ messages in thread From: Liliana Marie Prikler @ 2021-10-22 4:47 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Hi Ludo, Am Donnerstag, den 21.10.2021, 22:13 +0200 schrieb Ludovic Courtès: > Hi! > > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > > > let's say I wanted to add my own substitute server to my > > config.scm. > > At the time of writing, I would have to add said server's public > > key to > > the authorized-keys of my guix-configuration like so: > > (cons* (local-file "my-key.pub") %default-authorized-guix-keys) > > or similarily with append. This local-file incantation is however > > pretty weak. It changes based on the current working directory and > > even if I were to use an absolute path, I'd have to copy both that > > file > > and the config.scm to a new machine were I to use the same > > configuration there as well. > > Note that you could use ‘plain-file’ instead of ‘local-file’ and > inline the key canonical sexp in there. Yes, but for that I'd have to either write a (multi-line) string directly, which visibly "breaks" indentation of the rest of the file, or somehow generate a string which adds at least one layer of indentation. The former is imo unacceptable, the latter merely inconvenient. > > However, it turns out that the format for said key files is some > > actually pretty readable Lisp-esque stuff. For instance, an ECC > > key reads like > > (public-key (ecc (curve CURVE) (q #Q#))) > > with spaces omitted for simplicity. > > Were it not for the (q #Q#) bit, we could construct it using > > scheme-file. In fact, it is so simple that in my local config I > > now do exactly that. > > Yeah it’s frustrating that canonical sexps are almost, but not quite, > Scheme sexps. :-) > > (gcrypt pk-crypto) has a ‘canonical-sexp->sexp’ procedure: > > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> ,use(gcrypt pk-crypto) > scheme@(guile-user)> ,use(rnrs io ports) > scheme@(guile-user)> (string->canonical-sexp > (call-with-input-file > "etc/substitutes/ci.guix.info.pub" > get-string-all)) > $18 = #<canonical-sexp 7fce7f4e8b40 | 15d96a0> > scheme@(guile-user)> ,pp (canonical-sexp->sexp $18) > $19 = (public-key > (ecc (curve Ed25519) > (q #vu8(141 21 111 41 93 36 176 217 168 111 165 116 26 132 15 > 242 210 79 96 247 182 196 19 72 20 173 85 98 89 113 179 148)))) > --8<---------------cut here---------------end--------------->8--- > > > (define-record-type* <ecc-key> ...) > > (define-gexp-compiler (ecc-key-compiler (ecc-key <ecc-key>) ...) > > ...) > > > > (ecc-key > > (name "my-key.pub") > > (curve 'Ed25519) > > (q "ABCDE...")) > > > > Could/should we support such formats out of the box? WDYT? > > With this approach, we’d end up mirroring all the canonical sexps > used by libgcrypt, which doesn’t sound great from a maintenance POV. Given that we can use canonical sexps, what about a single canonical- sexp compiler then? I'd have to think about this a bit more when I have the time to, but having a way of writing the canonical sexp "directly" would imo be advantageous. > Would providing an example in the doc that uses ‘canonical-sexp- > >sexp’ and its dual help? I'm not sure whether it'd be in the doc or as a cookbook entry, but providing an example would in my opinion definitely help. I'll take a closer look at guile-gcrypt later. Hopefully they have scheme-ified constructors for everything, which would make this quite simple. Thanks, Liliana ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-10-22 4:47 ` Liliana Marie Prikler @ 2021-11-21 0:12 ` Jelle Licht 2021-11-21 8:28 ` Liliana Marie Prikler 0 siblings, 1 reply; 9+ messages in thread From: Jelle Licht @ 2021-11-21 0:12 UTC (permalink / raw) To: Liliana Marie Prikler, Ludovic Courtès; +Cc: guix-devel Hey folks, Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Hi Ludo, > > Am Donnerstag, den 21.10.2021, 22:13 +0200 schrieb Ludovic Courtès: >> Hi! >> >> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: >> >> > let's say I wanted to add my own substitute server to my >> > config.scm. >> > At the time of writing, I would have to add said server's public >> > key to >> > the authorized-keys of my guix-configuration like so: >> > (cons* (local-file "my-key.pub") %default-authorized-guix-keys) >> > or similarily with append. This local-file incantation is however >> > pretty weak. It changes based on the current working directory and >> > even if I were to use an absolute path, I'd have to copy both that >> > file >> > and the config.scm to a new machine were I to use the same >> > configuration there as well. >> >> Note that you could use ‘plain-file’ instead of ‘local-file’ and >> inline the key canonical sexp in there. > Yes, but for that I'd have to either write a (multi-line) string > directly, which visibly "breaks" indentation of the rest of the file, > or somehow generate a string which adds at least one layer of > indentation. The former is imo unacceptable, the latter merely > inconvenient. Would some arbitrary s-expression be a workable solution? See below for an example for what I understood was your current use-case. >> > However, it turns out that the format for said key files is some >> > actually pretty readable Lisp-esque stuff. For instance, an ECC >> > key reads like >> > (public-key (ecc (curve CURVE) (q #Q#))) >> > with spaces omitted for simplicity. >> > Were it not for the (q #Q#) bit, we could construct it using >> > scheme-file. In fact, it is so simple that in my local config I >> > now do exactly that. >> >> Yeah it’s frustrating that canonical sexps are almost, but not quite, >> Scheme sexps. :-) >> >> (gcrypt pk-crypto) has a ‘canonical-sexp->sexp’ procedure: >> >> --8<---------------cut here---------------start------------->8--- >> scheme@(guile-user)> ,use(gcrypt pk-crypto) >> scheme@(guile-user)> ,use(rnrs io ports) >> scheme@(guile-user)> (string->canonical-sexp >> (call-with-input-file >> "etc/substitutes/ci.guix.info.pub" >> get-string-all)) >> $18 = #<canonical-sexp 7fce7f4e8b40 | 15d96a0> >> scheme@(guile-user)> ,pp (canonical-sexp->sexp $18) >> $19 = (public-key >> (ecc (curve Ed25519) >> (q #vu8(141 21 111 41 93 36 176 217 168 111 165 116 26 132 15 >> 242 210 79 96 247 182 196 19 72 20 173 85 98 89 113 179 148)))) >> --8<---------------cut here---------------end--------------->8--- >> >> > (define-record-type* <ecc-key> ...) >> > (define-gexp-compiler (ecc-key-compiler (ecc-key <ecc-key>) ...) >> > ...) >> > >> > (ecc-key >> > (name "my-key.pub") >> > (curve 'Ed25519) >> > (q "ABCDE...")) >> > >> > Could/should we support such formats out of the box? WDYT? >> >> With this approach, we’d end up mirroring all the canonical sexps >> used by libgcrypt, which doesn’t sound great from a maintenance POV. > Given that we can use canonical sexps, what about a single canonical- > sexp compiler then? I'd have to think about this a bit more when I > have the time to, but having a way of writing the canonical sexp > "directly" would imo be advantageous. What about something such as the following? --8<---------------cut here---------------start------------->8--- (use-modules (gcrypt base16) (gcrypt pk-crypto)) (define-record-type <canonical-sexp-wrapper> (canonical-sexp-wrapper name sexp) canonical-sexp-wrapper? (name canonical-sexp-wrapper-name) (sexp canonical-sexp-wrapper-sexp)) (define-gexp-compiler (canonical-sexp-wrapper-compiler (wrapper <canonical-sexp-wrapper>) system target) (match wrapper (($ <canonical-sexp-wrapper> name sexp) (text-file name (canonical-sexp->string (sexp->canonical-sexp sexp)) '())))) --8<---------------cut here---------------end--------------->8--- This would still leave constructing your s-expression as an exercise to the reader, which is definitely not amazing. In this specific instance, I had to look at the output of canonical-sexp->sexp, which is of course whatever the opposite of discoverable and good UX :). For the Ed25519 key: --8<---------------cut here---------------start------------->8--- (define my-public-key (canonical-sexp-wrapper "my-key.pub" `(public-key (ecc (curve Ed25519) (q ,(base16-string->bytevector (string-downcase "C9F307AE..."))))))) --8<---------------cut here---------------end--------------->8--- To improve on this, is one sexp-based-gexp-compiler + N helper functions to construct the most-used value types a direction worth exploring? - Jelle ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-11-21 0:12 ` Jelle Licht @ 2021-11-21 8:28 ` Liliana Marie Prikler 2021-11-22 13:27 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Liliana Marie Prikler @ 2021-11-21 8:28 UTC (permalink / raw) To: Jelle Licht, Ludovic Courtès; +Cc: guix-devel Hi, Am Sonntag, den 21.11.2021, 01:12 +0100 schrieb Jelle Licht: > What about something such as the following? > > --8<---------------cut here---------------start------------->8--- > (use-modules (gcrypt base16) > (gcrypt pk-crypto)) > > (define-record-type <canonical-sexp-wrapper> > (canonical-sexp-wrapper name sexp) > canonical-sexp-wrapper? > (name canonical-sexp-wrapper-name) > (sexp canonical-sexp-wrapper-sexp)) > > (define-gexp-compiler (canonical-sexp-wrapper-compiler > (wrapper <canonical-sexp-wrapper>) system > target) > (match wrapper > (($ <canonical-sexp-wrapper> name sexp) > (text-file name (canonical-sexp->string > (sexp->canonical-sexp sexp)) '())))) > --8<---------------cut here---------------end--------------->8--- > > This would still leave constructing your s-expression as an exercise > to the reader, which is definitely not amazing. In this specific > instance, I had to look at the output of canonical-sexp->sexp, which > is of course whatever the opposite of discoverable and good UX :). Apart from the name "-wrapper" instead of "-file", I think this would be acceptable. I think we ought to handle two cases here, though: one with sexp being a sexp, and one with it being a canonical sexp. > For the Ed25519 key: > --8<---------------cut here---------------start------------->8--- > (define my-public-key > (canonical-sexp-wrapper > "my-key.pub" > `(public-key > (ecc > (curve Ed25519) > (q ,(base16-string->bytevector > (string-downcase > "C9F307AE..."))))))) > --8<---------------cut here---------------end--------------->8--- > > To improve on this, is one sexp-based-gexp-compiler + N helper > functions to construct the most-used value types a direction worth > exploring? I think we would probably want to improve on this end in the guile- gcrypt module, i.e. have a public-key "constructor" that returns a canonical-sexp and so on. WDYT? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-11-21 8:28 ` Liliana Marie Prikler @ 2021-11-22 13:27 ` Ludovic Courtès 2021-11-22 14:32 ` Jelle Licht 2021-11-22 19:35 ` Liliana Marie Prikler 0 siblings, 2 replies; 9+ messages in thread From: Ludovic Courtès @ 2021-11-22 13:27 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: guix-devel Hi, Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > I think we would probably want to improve on this end in the guile- > gcrypt module, i.e. have a public-key "constructor" that returns a > canonical-sexp and so on. WDYT? I don’t find it very compelling given there’s already ‘sexp->canonical-sexp’ & co. WDYT? Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-11-22 13:27 ` Ludovic Courtès @ 2021-11-22 14:32 ` Jelle Licht 2021-11-22 19:35 ` Liliana Marie Prikler 1 sibling, 0 replies; 9+ messages in thread From: Jelle Licht @ 2021-11-22 14:32 UTC (permalink / raw) To: Ludovic Courtès, Liliana Marie Prikler; +Cc: guix-devel Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > >> I think we would probably want to improve on this end in the guile- >> gcrypt module, i.e. have a public-key "constructor" that returns a >> canonical-sexp and so on. WDYT? > > I don’t find it very compelling given there’s already > ‘sexp->canonical-sexp’ & co. WDYT? Well, the issue here is 'knowing' what sexp to pass along to that function in the first place. Are Liliana & I missing something obvious here? I had to take a string representation of a valid canonical-sexp, and pass it through string->canonical-sexp and canonical-sexp->sexp. It's definitely not an issue for managing my local configuration, but it seems silly to force _anyone_ wanting to write a canonical-sexp as a sexp through this REPL adventure, for each kind of canonical-sexp. - Jelle ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-11-22 13:27 ` Ludovic Courtès 2021-11-22 14:32 ` Jelle Licht @ 2021-11-22 19:35 ` Liliana Marie Prikler 2021-11-23 17:14 ` Ludovic Courtès 1 sibling, 1 reply; 9+ messages in thread From: Liliana Marie Prikler @ 2021-11-22 19:35 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Am Montag, den 22.11.2021, 14:27 +0100 schrieb Ludovic Courtès: > Hi, > > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > > > I think we would probably want to improve on this end in the guile- > > gcrypt module, i.e. have a public-key "constructor" that returns a > > canonical-sexp and so on. WDYT? > > I don’t find it very compelling given there’s already > ‘sexp->canonical-sexp’ & co. WDYT? sexp->canonical-sexp is from the comment surrounding it a rather hacky beast. I think (guile-)gcrypt could very well benefit from having a better sexp construction API, but again that's outside the scope of Guix. But since you're asking, I do feel there's a lot guile-gcrypt could borrow from Guix, just not right now in an efficient manner thanks to needing to jump through the sexp->canonical-sexp hoops. It could have semantic constructors and field sanitization à la (guix records) for example. WDYT? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using G-Expressions for public keys (substitutes and possibly more) 2021-11-22 19:35 ` Liliana Marie Prikler @ 2021-11-23 17:14 ` Ludovic Courtès 0 siblings, 0 replies; 9+ messages in thread From: Ludovic Courtès @ 2021-11-23 17:14 UTC (permalink / raw) To: Liliana Marie Prikler; +Cc: guix-devel Liliana Marie Prikler <liliana.prikler@gmail.com> skribis: > Am Montag, den 22.11.2021, 14:27 +0100 schrieb Ludovic Courtès: [...] > sexp->canonical-sexp is from the comment surrounding it a rather hacky > beast. I think (guile-)gcrypt could very well benefit from having a > better sexp construction API, but again that's outside the scope of > Guix. > > But since you're asking, I do feel there's a lot guile-gcrypt could > borrow from Guix, just not right now in an efficient manner thanks to > needing to jump through the sexp->canonical-sexp hoops. It could have > semantic constructors and field sanitization à la (guix records) for > example. WDYT? Fundamentally, Guile-Gcrypt is just bindings to libgcrypt. As such, it tries hard to remain close to libgcrypt’s API, and I think that’s a safe approach for bindings in general. Libgcrypt internally uses canonical sexps for key material, configuration options, etc. (an illustration of Greenspun’s Tenth Rule :-)), so that’s what Guile-Gcrypt exposes, and I think it’s fine. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-11-23 17:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-17 12:47 Using G-Expressions for public keys (substitutes and possibly more) Liliana Marie Prikler 2021-10-21 20:13 ` Ludovic Courtès 2021-10-22 4:47 ` Liliana Marie Prikler 2021-11-21 0:12 ` Jelle Licht 2021-11-21 8:28 ` Liliana Marie Prikler 2021-11-22 13:27 ` Ludovic Courtès 2021-11-22 14:32 ` Jelle Licht 2021-11-22 19:35 ` Liliana Marie Prikler 2021-11-23 17:14 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).