From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YNGKAt7BYWJRCAEAbAwnHQ (envelope-from ) for ; Thu, 21 Apr 2022 22:43:10 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YLOPAt7BYWKkXQAA9RJhRA (envelope-from ) for ; Thu, 21 Apr 2022 22:43:10 +0200 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 94ED52CC70 for ; Thu, 21 Apr 2022 22:43:09 +0200 (CEST) Received: from localhost ([::1]:47698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhdds-0000NT-9D for larch@yhetil.org; Thu, 21 Apr 2022 16:43:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhddm-0000NA-2W for guix-patches@gnu.org; Thu, 21 Apr 2022 16:43:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57088) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhddl-0007XC-Q4 for guix-patches@gnu.org; Thu, 21 Apr 2022 16:43:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nhddl-0004ye-Lr for guix-patches@gnu.org; Thu, 21 Apr 2022 16:43:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55055] Fwd: [bug#55055] [PATCH] gnu: wireguard: Add support for PresharedKey Resent-From: Paul Alesius Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 21 Apr 2022 20:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55055 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 55055@debbugs.gnu.org Received: via spool by 55055-submit@debbugs.gnu.org id=B55055.165057375719096 (code B ref 55055); Thu, 21 Apr 2022 20:43:01 +0000 Received: (at 55055) by debbugs.gnu.org; 21 Apr 2022 20:42:37 +0000 Received: from localhost ([127.0.0.1]:50985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhddM-0004xw-RW for submit@debbugs.gnu.org; Thu, 21 Apr 2022 16:42:37 -0400 Received: from mail-yw1-f182.google.com ([209.85.128.182]:42100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhddL-0004xg-9L for 55055@debbugs.gnu.org; Thu, 21 Apr 2022 16:42:36 -0400 Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2ef5380669cso65046587b3.9 for <55055@debbugs.gnu.org>; Thu, 21 Apr 2022 13:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unnservice-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WZB5pPjayI492GcOdxbP3s2Gdn3oC8w1Xkc7LcL/J18=; b=4GC55rRXG3Y7bYcTtI+sO2aQWOClDY1tj24ZG2decYYiu3P0TbBvBR5pAAvuux1ZLf s5uW75JlXb/R5M79nC14n1fuT72xHalpCSb16WpwmebcoIyUZ7SHkHpAJGtravrvLq0Z FDyuUBc8pE1VzI1GVsnhEmHi0hxdYuPIcMqsjsOLVwO9adHmCIA+H21Krckv2EXbuRHf OlW7A2cQavdDRcqiv4a4eUSOyS5epibok6UtL/cwBD7oEJeiRFgDU71wz0qIFKx7Ep2i WruoK5SFEYLbDw0HhK41UTynkzlJ3qoFTGOnqQhimz2NLUWogQ4IUDA6nhvqex0cCRin BZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WZB5pPjayI492GcOdxbP3s2Gdn3oC8w1Xkc7LcL/J18=; b=lMAgPQOlcKUGVyRDWxx1o/f/b1TQiwK9H3JbxvtokF6LuUnEIBq1PByoQ5ZZMtroFL Mvt3mNl/l4V6s+3O69ggsPpWzTRUio5RauFEJX4bZU4foM3FTrM+iJAx8vqVOh/jFPSp lMPGQCdHz7biQUwmGygdRsZJf5DAKE8x1VfkP5JiPllTjslx1KuPHu79fWJSJwNK2jrB ichPBYBAprYJBqDope6iDvC3Nm7DwuHpu9CAbFkfu5yLDHYd9EDtYrX+Cvnlk5NG9+Hm WZcChQhAhKIAi0+bU67sPvJuHmuc8M78c9Q3ECSOriuP+ElYB523eABfViovyfw1oprb fK0g== X-Gm-Message-State: AOAM533Owr+J6wkrfHy7h6iigrX5Ou6d1CECiF1i9SATyqOus8rpyUE5 dLQlVmidJ0vU4irkTZAbjK9kwr+bg5ZVNM7eZ9pAzDq4FAX+ X-Google-Smtp-Source: ABdhPJzcCi10WwLb/+u+MK9DMdklUSEJDplsCUax309VOw7SQtgWzhcLVrWSHFcuQleijmHrzCARWIp8NoQo7aBn7FI= X-Received: by 2002:a81:4f14:0:b0:2ec:496b:cb29 with SMTP id d20-20020a814f14000000b002ec496bcb29mr1726633ywb.159.1650573749422; Thu, 21 Apr 2022 13:42:29 -0700 (PDT) MIME-Version: 1.0 References: <274c06a235949ebbdd3f90e31afea1189f207ea0.camel@telenet.be> In-Reply-To: From: Paul Alesius Date: Thu, 21 Apr 2022 22:41:53 +0200 Message-ID: Content-Type: multipart/alternative; boundary="000000000000029f2a05dd30262a" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650573789; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=WZB5pPjayI492GcOdxbP3s2Gdn3oC8w1Xkc7LcL/J18=; b=C9l5kQ2YCvGr749/ZRkrfHajsZ4JHK3xhU1gMfjR0HyqgPFSoIMSnqFBMepa5nalOjQ6p0 gWhGksaMghU3+DRVHprnIXlxBla0GlNitD6xQyBr00d9/7t1DXTkETU4+SdiMQjVwnP9yE o+6dyqFgtwjTqA81NTz7MIow5zrwN0XhKLR4QlH3P18Iyj8M1m5CHgvXjOkm+rwzfgqvj/ oW3INBJLuim5pzRnTPDK648VpL9Bjw4unrE31Fg1BzVsu18yJdJYJI9nDi1gnRGAIEJtdN LuQWNrwB3n3Y+FBEy7/4RwcSk8CTIlMWgFdsPQtITtsgaxu5vqgFj5U1rCuFkA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650573789; a=rsa-sha256; cv=none; b=pIRuW8aBFQ0JVpqGm716pwu4g6ox4X4n0gSFRC4g4Gvsf5i7E/mrlpjXWaEoUjceamcPph eaDxVigFf09E56uGnMPx2Y3MR3TsXs7lKHBEcLe6o4ZFv2ahnJuCn0dZP0F4Ox7i5Ewujg NC7IcwNdzYXW0LKtshbo0bH5nLfEqzUiPkQhP9ZQN0gDShz1d287pZ9t/MJ/z1cNrYWC4+ 94pnPd7oWqFd11YpFKghCqT6BJ8AGpxHkrqCo+lWEinBysIC6tp7N+VCCU1sAMfv0APZZe 61E+JqZ/8r2w7MaOk12Zh+DboWFG1fPuMQ0jV6YCUhHcDZjb5TEGMUfrLaIFhg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=unnservice-com.20210112.gappssmtp.com header.s=20210112 header.b=4GC55rRX; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 0.67 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=unnservice-com.20210112.gappssmtp.com header.s=20210112 header.b=4GC55rRX; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 94ED52CC70 X-Spam-Score: 0.67 X-Migadu-Scanner: scn0.migadu.com X-TUID: V1kUzZpN7Whj --000000000000029f2a05dd30262a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Also, #f is not a string, did you mean =E2=80=98;#f|string=E2=80=99? The idea behind #f is that the field is optional, so that if it isn't specified in the configuration then it isn't written to the configuration file at all, hence #f is for a conditional when writing the actual configuration file and has no default value. > * Could the security limitation be documented? > * Does wireguard has some inclusion mechanism, such that the wireguard configuration can =E2=80=98include=E2=80=99 some file outside the store? I'll fix it properly to allow for loading of a key file, WireGuard does not have an inclusion mechanism. How does it work with regards to documentation and i18n versions, do you use online translation for the other languages? I can really only fill in the english version. > * What security impact does a leaked secret key have? Minimal to none, one should worry about the cloud peers over the wire guard pre-shared key. It's just an additional layer of security in case the public key algorithms are broken (for instance with quantum decryption), then the pre-shared key functions as a one-time pad. If none is specified, wireguard will use a default one of an all-zero string. Since countries log all traffic, you never know what they have, hence my patch submission. > * WDYT of verifying that the preshared key looks =E2=80=98reasonable=E2= =80=99 (I guess only a-z0-9 characters, no spaces or newlines, not a bytevector ...) I could develop a subsystem for validating the fields of the wireguard but isn't it better to provide validations from the guix framework more broadly? With my level of Guile scripting right now, I doubt that it would be accepted. With regards, - Paul On Thu, 21 Apr 2022 at 16:26, Maxime Devos wrote: > Paul Alesius schreef op do 21-04-2022 om 15:26 [+0200]: > > + (preshared-key wireguard-peer-preshared-key > > + (default #f)) ;string > > This should be documented in the documentation, otherwise it will be > difficult to discover. Also, #f is not a string, did you mean > =E2=80=98;#f|string=E2=80=99? > > Also, a limitation: the preshared key will end up in the store, and > hence be world-readable. So other users on the same system (other > people or compromised system daemons) could now determine the preshared > key. > > Questions: > > * Could the security limitation be documented? > > * What security impact does a leaked secret key have? > > * Does wireguard has some inclusion mechanism, such that the > wireguard configuration can =E2=80=98include=E2=80=99 some file outsi= de the store? > > * WDYT of verifying that the preshared key looks =E2=80=98reasonable=E2= =80=99 > (I guess only a-z0-9 characters, no spaces or newlines, not a > bytevector ...) > > As-is, if I do (preshared-keys (string->utf8 "oops I thought this > needs to be bytevector)) then "guix system reconfigure" doesn't > give a nice error message, it will just silently produce a broken > configuration file. > > Greetings, > Maxime. > --000000000000029f2a05dd30262a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Also, #f is not a string, did you mean =E2=80=98;#f|= string=E2=80=99?

=
The idea behind #f is that the field is optional, so that if it isn= 9;t specified in the configuration then it isn't written to the configu= ration file at all, hence #f is for a conditional when writing the actual c= onfiguration file and has no default value.

&g= t;=C2=A0 * Could the security limitation be documented?
> * D= oes wireguard has some inclusion mechanism, such that the wireguard configu= ration can =E2=80=98include=E2=80=99 some file outside the store?

I'll fix it properly to allow for loading of a key file= , WireGuard does not have an inclusion mechanism. How does it work with reg= ards to documentation and i18n versions, do you use online translation for = the other languages? I can really only fill in the english version.

>=20 =C2=A0 * What security impact does a leaked secret key have?

=
Minimal to none, one should worry about the cloud peers over the= wire guard pre-shared key. It's just an additional layer of security i= n case the public key algorithms are broken (for instance with quantum decr= yption), then the pre-shared key functions as a one-time pad. If none is sp= ecified, wireguard will use a default one of an all-zero string.
=
Since countries log all traffic, you never know what they ha= ve, hence my patch submission.

> * WDYT of = verifying that the preshared key looks =E2=80=98reasonable=E2=80=99 (I gues= s only a-z0-9 characters, no spaces or newlines, not a bytevector ...)

I could develop a subsystem for validating the fields = of the wireguard but isn't it better to provide validations from the gu= ix framework more broadly? With my level of Guile scripting right now, I do= ubt that it would be accepted.

With regards,
- Paul

On Thu, 21 Apr 2022 at 16:26, Maxime Devos <maximedevos@telene= t.be> wrote:
Paul Alesius schreef op do 21-04-2022 om 15:26 [+0200]:
> +=C2=A0 (preshared-key=C2=A0 =C2=A0 =C2=A0wireguard-peer-preshared-key=
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(default #f))=C2=A0 =C2=A0;string

This should be documented in the documentation, otherwise it will be
difficult to discover.=C2=A0 Also, #f is not a string, did you mean
=E2=80=98;#f|string=E2=80=99?

Also, a limitation: the preshared key will end up in the store, and
hence be world-readable.=C2=A0 So other users on the same system (other
people or compromised system daemons) could now determine the preshared
key.

Questions:

=C2=A0 * Could the security limitation be documented?

=C2=A0 * What security impact does a leaked secret key have?

=C2=A0 * Does wireguard has some inclusion mechanism, such that the
=C2=A0 =C2=A0 wireguard configuration can =E2=80=98include=E2=80=99 some fi= le outside the store?

=C2=A0 * WDYT of verifying that the preshared key looks =E2=80=98reasonable= =E2=80=99
=C2=A0 =C2=A0 (I guess only a-z0-9 characters, no spaces or newlines, not a=
=C2=A0 =C2=A0 bytevector ...)

=C2=A0 =C2=A0 As-is, if I do (preshared-keys (string->utf8 "oops I = thought this
=C2=A0 =C2=A0 needs to be bytevector)) then "guix system reconfigure&q= uot; doesn't
=C2=A0 =C2=A0 give a nice error message, it will just silently produce a br= oken
=C2=A0 =C2=A0 configuration file.

Greetings,
Maxime.
--000000000000029f2a05dd30262a--