GNU bug report logs - #55055
[PATCH] gnu: wireguard: Add support for PresharedKey

Previous Next

Full log

Message #11 received at 55055 <at> debbugs.gnu.org (full text, mbox):

From: Paul Alesius <paul <at> unnservice.com>
To: 55055 <at> debbugs.gnu.org
Subject: Fwd: [bug#55055] [PATCH] gnu: wireguard: Add support for PresharedKey
Date: Thu, 21 Apr 2022 22:41:53 +0200

[Message part 1 (text/plain, inline)]

> Also, #f is not a string, did you mean ‘;#f|string’?

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 ‘include’ 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 ‘reasonable’ (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 <maximedevos <at> telenet.be> 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
> ‘;#f|string’?
>
> 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 ‘include’ some file outside the store?
>
>   * WDYT of verifying that the preshared key looks ‘reasonable’
>     (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.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.