From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AHmVCgmPmWH/NAAAgWs5BA (envelope-from ) for ; Sun, 21 Nov 2021 01:12:57 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GJMrBgmPmWFbUQAAbx9fmQ (envelope-from ) for ; Sun, 21 Nov 2021 00:12:57 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BAD3F7740 for ; Sun, 21 Nov 2021 01:12:56 +0100 (CET) Received: from localhost ([::1]:55102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1moaTX-0001fh-SY for larch@yhetil.org; Sat, 20 Nov 2021 19:12:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moaTN-0001fK-IL for guix-devel@gnu.org; Sat, 20 Nov 2021 19:12:45 -0500 Received: from [2001:aa8:ffed:f5f3::151] (port=32908 helo=mail1.fsfe.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moaTJ-0007Ez-HC; Sat, 20 Nov 2021 19:12:45 -0500 From: Jelle Licht DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2021100501; t=1637453547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TJt8/PTOrh/z2jKYGLEqv7zYdiFr6j7dWNgpvqmjB5I=; b=fbKUCHQHi4aiUhHe2Grxak07o765sAYvvr7dF4XqVR0Q7Ey/LCGVDIOfMFzvxbb65b69xv gHTuZfihjGX09j4hEF82BQwLZbkLWol9l12EKDZ49Pnxsv08A4++UjVAZFdh8I9iMAAp7C ECDLF8g83C/1lgBSzwdmmRwKZ4vwIN8= To: Liliana Marie Prikler , Ludovic =?utf-8?Q?C?= =?utf-8?Q?ourt=C3=A8s?= Subject: Re: Using G-Expressions for public keys (substitutes and possibly more) In-Reply-To: References: <5f7e587c376ed0abffa321152e185cbf4014e05b.camel@gmail.com> <87wnm6w2yz.fsf@gnu.org> Date: Sun, 21 Nov 2021 01:12:27 +0100 Message-ID: <86k0h2jris.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:aa8:ffed:f5f3::151 (failed) Received-SPF: pass client-ip=2001:aa8:ffed:f5f3::151; envelope-from=jlicht@fsfe.org; helo=mail1.fsfe.org X-Spam_score_int: -62 X-Spam_score: -6.3 X-Spam_bar: ------ X-Spam_report: (-6.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637453576; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=TJt8/PTOrh/z2jKYGLEqv7zYdiFr6j7dWNgpvqmjB5I=; b=YUFayTUo+ywXOzdH71bCN/w8mvqs5obnyZU3NKwS4f6qwp64Ig8aAueLIahHN+PlkSmp30 VH7qKg2dS82XsF8DNnbjVq0EmqRtDoiPrg37N+9tM4W8KOKVThaO862cFZUqvU/oy8kgvF 0GL1v1I18xAFRDjtSITREogw+sX/7wrY472+9/Y5NTW7BM5Vbe5NqC+Q+yBo5cKSkLMxXe QMHiIz2cuPCGPeT6aOAXTXcniAaf0unwj4RpSom2faq/SFW0uPOqpqV11fLsFJVXNUX7TI vSKhUzq9MxPlqrlj4zYDeXZrSH+XOJb9enAycdOFXmC7zpjkqPAdhSls1s7aWw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637453576; a=rsa-sha256; cv=none; b=dszMTPMp/C+CoEFY3v7xYFfzIEr12ZEgAlktV8+hJt0n950G3VSks7AmIiEvxBJcjS7rty Ah5OG8Gqt5HwMTmLgKVppGLQKOflkQyU8wcEn54PpEZy36dCy7eiNvfJYPR1GCRIiqGOsL xgiHQJRwKW8hbnOuPrGnbtLkvf+6lAuTwXntKYDzfH9Z4fA3wakw2vA8d+CiwFimx/lxUo UR7I2DVeHiXAvL8KvV2MJhB0c0DH8Nza29XcS55+VuV8w3SbWOqmQGO+ZvOynbCjaHnUdk 8FnUBiTWWgYyoi1R+Zsq2ysDG4FcqBUZ6yZ29K/RfYFmqqRlkcXRiILJwGDpqw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021100501 header.b=fbKUCHQH; dmarc=pass (policy=none) header.from=fsfe.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -7.57 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021100501 header.b=fbKUCHQH; dmarc=pass (policy=none) header.from=fsfe.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: BAD3F7740 X-Spam-Score: -7.57 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5sPMyxO0oNMk Hey folks, Liliana Marie Prikler writes: > Hi Ludo, > > Am Donnerstag, den 21.10.2021, 22:13 +0200 schrieb Ludovic Court=C3=A8s: >> Hi! >>=20 >> Liliana Marie Prikler skribis: >>=20 >> > let's say I wanted to add my own substitute server to my >> > config.scm.=20 >> > 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. >>=20 >> Note that you could use =E2=80=98plain-file=E2=80=99 instead of =E2=80= =98local-file=E2=80=99 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. >>=20 >> Yeah it=E2=80=99s frustrating that canonical sexps are almost, but not q= uite, >> Scheme sexps. :-) >>=20 >> (gcrypt pk-crypto) has a =E2=80=98canonical-sexp->sexp=E2=80=99 procedur= e: >>=20 >> --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 =3D # >> scheme@(guile-user)> ,pp (canonical-sexp->sexp $18) >> $19 =3D (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--- >>=20 >> > (define-record-type* ...) >> > (define-gexp-compiler (ecc-key-compiler (ecc-key ) ...) >> > ...) >> >=20 >> > (ecc-key >> > (name "my-key.pub") >> > (curve 'Ed25519) >> > (q "ABCDE...")) >> >=20 >> > Could/should we support such formats out of the box? WDYT? >>=20 >> With this approach, we=E2=80=99d end up mirroring all the canonical sexps >> used by libgcrypt, which doesn=E2=80=99t 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 name sexp) canonical-sexp-wrapper? (name canonical-sexp-wrapper-name) (sexp canonical-sexp-wrapper-sexp)) (define-gexp-compiler (canonical-sexp-wrapper-compiler (wrapper ) system target) (match 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