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