* Re: Reflections on WireGuard Design Goals [not found] <mailman.1318.1533866648.2201.wireguard@lists.zx2c4.com> @ 2018-08-10 13:35 ` Brian Candler 2018-08-10 14:09 ` Matthias Urlichs ` (6 more replies) 0 siblings, 7 replies; 20+ messages in thread From: Brian Candler @ 2018-08-10 13:35 UTC (permalink / raw) To: wireguard > For whatever reason, in the last several weeks, WireGuard been receivin= g a > considerable amount of attention, and with that comes various parties > interested in the project moving in this direction or in that direction= . And > more generally, over the last year or so, we've seen a decent amount of > interest from different folks wanting to do different things with the p= roject > and with the protocol. This inevitably leads to the question: what do w= e > actually want WireGuard to be, as a project, as a protocol, as a set of > implementations, as a design methodology, and so forth? I've had a pret= ty > clear idea about that, but I don't think I've ever tried to communicate > aspects of it in this context, so I thought here I'd highlight two impo= rtant > design goals that motivate us. Thanks for explaining the project background, and your very sensible=20 goals of simplicity and robustness.=C2=A0 And thanks for releasing this=20 excellent piece of software. From my point of view, the only thing which makes me uncomfortable=20 about wireguard is the lack of any second authentication factor. Your=20 private key is embedded in a plaintext file in your device (e.g.=20 laptop), not even protected with a passphrase.=C2=A0 Anyone who gains acc= ess=20 to that laptop is able to establish wireguard connections. Of course, it can be argued that the laptop holds other information=20 which is more valuable that the wireguard key, therefore you should=20 concentrate on properly securing the laptop itself (*). Furthermore, to=20 be able to talk to the wireguard kernel module you're already root, and=20 therefore have all sorts of malicious options available to you. etc etc But I'd feel a lot happier if a second level of authentication were=20 required to establish a wireguard connection, if no packets had been=20 flowing for more than a configurable amount of time - say, an hour. It=20 would give some comfort around lost/stolen devices. Whilst I appreciate that wireguard is symmetrical, a common use case is=20 to have remote "clients" with a central "office".=C2=A0 I'm thinking abou= t a=20 hook whereby the "office" side could request extra authentication when=20 required - e.g. if it sees a connection from a wireguard public key=20 which has been idle for more than a configurable amount of time, then it=20 sends a challenge which requires (e.g.) a Yubikey to complete.=C2=A0 I=20 appreciate that it's not going to be straightforward, requiring the=20 kernel module to talk to userland components at both ends. In the absence of that, it would be nice if the private key which is=20 stored on the laptop were encrypted with a passphrase.=C2=A0 Simplest opt= ion=20 may be to extend wg-quick so that the entire config file can be=20 pgp-encrypted. Regards, Brian. (*) You could make a similar argument for ssh keys or pgp keys, saying=20 there's no need to protect them with a passphrase if the host they are=20 stored on is properly secured.=C2=A0 I think many people would disagree. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler @ 2018-08-10 14:09 ` Matthias Urlichs 2018-08-10 14:09 ` Kalin KOZHUHAROV ` (5 subsequent siblings) 6 siblings, 0 replies; 20+ messages in thread From: Matthias Urlichs @ 2018-08-10 14:09 UTC (permalink / raw) To: wireguard [-- Attachment #1.1: Type: text/plain, Size: 1363 bytes --] On 10.08.2018 15:35, Brian Candler wrote: > Whilst I appreciate that wireguard is symmetrical, a common use case > is to have remote "clients" with a central "office". I'm thinking > about a hook whereby the "office" side could request extra > authentication when required - e.g. if it sees a connection from a > wireguard public key which has been idle for more than a configurable > amount of time, then it sends a challenge which requires (e.g.) a > Yubikey to complete. I appreciate that it's not going to be > straightforward, requiring the kernel module to talk to userland > components at both ends. It's reasonably easy to add that as a service on top of Wireguard, once you have an authenticated connection. The office can easily talk to an app on the mobile device when it notices a re-awakened stale connection (triggered by a firewall logging rule, for instance), exchange whatever crypto it requires, and only then allow packets other than those required for authenticating to flow through the interface (another simple firewall rule change). Adding a feature like this to the WG kernel itself would not be any more secure (and indeed add a significant amount of complexity which may exhibit exploitable bugs). It would also unnecessarily enshrine a particular 2FA scheme into wireguard. -- -- Matthias Urlichs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler 2018-08-10 14:09 ` Matthias Urlichs @ 2018-08-10 14:09 ` Kalin KOZHUHAROV 2018-08-10 14:42 ` Eisfunke ` (4 subsequent siblings) 6 siblings, 0 replies; 20+ messages in thread From: Kalin KOZHUHAROV @ 2018-08-10 14:09 UTC (permalink / raw) To: Brian Candler; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 3108 bytes --] Please excuse my brevity, phone typing here... On Fri, 10 Aug 2018, 16:36 Brian Candler, <b.candler@pobox.com> wrote: > Thanks for explaining the project background, and your very sensible > goals of simplicity and robustness. And thanks for releasing this > excellent piece of software. > > From my point of view, the only thing which makes me uncomfortable > about wireguard is the lack of any second authentication factor. Your > private key is embedded in a plaintext file in your device (e.g. > laptop), not even protected with a passphrase. Not always. You can generate it on the fly (say 1st boot, no config file), distribute it and be done. Or you can choose to protect it (e.g. pgp), may be even store it in a HSM. Or throw it (keep in RAM) and regenerate, if needed. Anyone who gains access > to that laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > And what do we do (count or not) keepalive traffic? Whilst I appreciate that wireguard is symmetrical, a common use case is > to have remote "clients" with a central "office". I'm thinking about a > hook whereby the "office" side could request extra authentication when > required - e.g. if it sees a connection from a wireguard public key > which has been idle for more than a configurable amount of time, then it > sends a challenge which requires (e.g.) a Yubikey to complete. I > appreciate that it's not going to be straightforward, requiring the > kernel module to talk to userland components at both ends. > That is way overcomplicated... And how did you solve your key distribution in such scenario BTW? (hint: the functionality you request is part of key handling, i.e. NOT part of wg, AFAIK). The office end can expire any user key and request sidechannel (additional, 2FA or more) authentication via the established link. Who says wg tunnel should be to the network core? Use a standard firewall, plug a RADIUS even, or script your way on top of wg. Feel free to provide a clean interface to wg and documentation and people who want that functionality will use the code. Is there anything (e.g. design-level) that prevents that? Or functionality that is lacking at the core? > > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. > Now that also is not 2FA, and yes it should be a few lines of scripting. Kalin. [-- Attachment #2: Type: text/html, Size: 4434 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler 2018-08-10 14:09 ` Matthias Urlichs 2018-08-10 14:09 ` Kalin KOZHUHAROV @ 2018-08-10 14:42 ` Eisfunke 2018-08-10 14:47 ` Konstantin Ryabitsev ` (3 subsequent siblings) 6 siblings, 0 replies; 20+ messages in thread From: Eisfunke @ 2018-08-10 14:42 UTC (permalink / raw) To: wireguard; +Cc: Brian Candler Hello together, > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. one can already do that via the wg-quick PostUp hook, check out the Arch Linux wiki: https://wiki.archlinux.org/index.php/ WireGuard#Store_private_keys_in_encrypted_form The example is using pass, switching it for direct GPG (or keepassxc or anything, really) should be easily possible. Considering that possibility, I don't think adding GnuPG directly into Wireguard would be a good idea. It would just add complexity for little to no benefit. Greetings, NIcolas Lenz ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler ` (2 preceding siblings ...) 2018-08-10 14:42 ` Eisfunke @ 2018-08-10 14:47 ` Konstantin Ryabitsev 2018-08-10 15:03 ` Roman Mamedov ` (2 subsequent siblings) 6 siblings, 0 replies; 20+ messages in thread From: Konstantin Ryabitsev @ 2018-08-10 14:47 UTC (permalink / raw) To: Brian Candler; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 2842 bytes --] On Fri, Aug 10, 2018 at 02:35:14PM +0100, Brian Candler wrote: >From my point of view, the only thing which makes me uncomfortable >about wireguard is the lack of any second authentication factor. Your >private key is embedded in a plaintext file in your device (e.g. >laptop), not even protected with a passphrase. Anyone who gains access >to that laptop is able to establish wireguard connections. I think one way of solving this is teaching the client-side tools to hook into the TPM. We still grab the key and store it in memory (as opposed to using TPM's crypto processing directly), but at least this way it's not lying around on disk somewhere, and it doesn't require changing anything about the protocol. I am hoping to hit up James Bottomley about it when I next see him -- he's already written quite a few tools that use TPM, including teaching GnuPG how to use it. :) >But I'd feel a lot happier if a second level of authentication were >required to establish a wireguard connection, if no packets had been >flowing for more than a configurable amount of time - say, an hour. It >would give some comfort around lost/stolen devices. I believe this is orthogonal to the design of the protocol, which is supposed to behave in a "stateless" fashion and resume transparently after even prolonged downtimes. We use 2-factor authentication with OpenVPN, and one of the most annoying aspects about it is the fact that you have to manually re-auth after each VPN blip. If you don't do it quickly enough, all your sessions get reset -- most horrible experience if you are hoping your ssh connection to a server doesn't get severed in the middle of a yum update. >Whilst I appreciate that wireguard is symmetrical, a common use case is >to have remote "clients" with a central "office". I'm thinking about a >hook whereby the "office" side could request extra authentication when >required - e.g. if it sees a connection from a wireguard public key >which has been idle for more than a configurable amount of time, then >it sends a challenge which requires (e.g.) a Yubikey to complete. I >appreciate that it's not going to be straightforward, requiring the >kernel module to talk to userland components at both ends. I think Wireguard's primary strength is its resilience to network blips and fast operation. We intend to use it for site-to-site connectivity across disjointed infrastructure where it will certainly operate much smoother than OpenVPN or ipsec. For admin-to-site connections we will continue to use OpenVPN or some combination thereof, until we figure out a straightforward way of "upgrading" access level of a wireguard connection. I suspect this is fairly easy with iptables and fwmark, but I need to test and streamline it. -K [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler ` (3 preceding siblings ...) 2018-08-10 14:47 ` Konstantin Ryabitsev @ 2018-08-10 15:03 ` Roman Mamedov 2018-08-10 16:03 ` Brian Candler 2018-08-10 20:15 ` em12345 2018-08-11 19:18 ` Jason A. Donenfeld 6 siblings, 1 reply; 20+ messages in thread From: Roman Mamedov @ 2018-08-10 15:03 UTC (permalink / raw) To: Brian Candler; +Cc: wireguard On Fri, 10 Aug 2018 14:35:14 +0100 Brian Candler <b.candler@pobox.com> wrote: > From my point of view, the only thing which makes me uncomfortable=20 > about wireguard is the lack of any second authentication factor. Your=20 > private key is embedded in a plaintext file in your device (e.g.=20 > laptop), not even protected with a passphrase.=C2=A0 Anyone who gains acc= ess=20 > to that laptop is able to establish wireguard connections. >=20 > Of course, it can be argued that the laptop holds other information=20 > which is more valuable that the wireguard key, therefore you should=20 > concentrate on properly securing the laptop itself (*). Furthermore, to=20 > be able to talk to the wireguard kernel module you're already root, and=20 > therefore have all sorts of malicious options available to you. etc etc >=20 > But I'd feel a lot happier if a second level of authentication were=20 > required to establish a wireguard connection, if no packets had been=20 > flowing for more than a configurable amount of time - say, an hour. It=20 > would give some comfort around lost/stolen devices. Couldn't you just encrypt your home directory? Or even the root FS entirely. Either of those should be a must on a portable device storing valuable information. --=20 With respect, Roman ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 15:03 ` Roman Mamedov @ 2018-08-10 16:03 ` Brian Candler 2018-08-10 16:38 ` Kalin KOZHUHAROV 2018-08-10 16:40 ` jungle Boogie 0 siblings, 2 replies; 20+ messages in thread From: Brian Candler @ 2018-08-10 16:03 UTC (permalink / raw) To: Roman Mamedov; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 580 bytes --] On 10/08/2018 16:03, Roman Mamedov wrote: >> But I'd feel a lot happier if a second level of authentication were >> required to establish a wireguard connection, if no packets had been >> flowing for more than a configurable amount of time - say, an hour. It >> would give some comfort around lost/stolen devices. > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. But by analogy, would you say that SSH keys and PGP keys don't need protection by a passphrase? [-- Attachment #2: Type: text/html, Size: 1007 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 16:03 ` Brian Candler @ 2018-08-10 16:38 ` Kalin KOZHUHAROV 2018-08-10 16:40 ` jungle Boogie 1 sibling, 0 replies; 20+ messages in thread From: Kalin KOZHUHAROV @ 2018-08-10 16:38 UTC (permalink / raw) To: Brian Candler; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 839 bytes --] On Fri, 10 Aug 2018, 19:04 Brian Candler, <b.candler@pobox.com> wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > Yes, I will say so. I (almost) never use it, it is either too unsecure yet cumbersome, so I use separate devices (nFA), encrypted FS, etc. where needed. Or nothing at all. Kalin. [-- Attachment #2: Type: text/html, Size: 1494 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 16:03 ` Brian Candler 2018-08-10 16:38 ` Kalin KOZHUHAROV @ 2018-08-10 16:40 ` jungle Boogie 2018-08-10 17:12 ` Aaron Jones 1 sibling, 1 reply; 20+ messages in thread From: jungle Boogie @ 2018-08-10 16:40 UTC (permalink / raw) To: Brian Candler; +Cc: WireGuard mailing list On 10 August 2018 at 09:03, Brian Candler <b.candler@pobox.com> wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection, if no packets had been > flowing for more than a configurable amount of time - say, an hour. It > would give some comfort around lost/stolen devices. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > If someone already has my ssh key, I'd revoke it - regardless if they had the password or not. Same with the WG key - shutdown the tunnel, remove the affected peer and start it back up. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 16:40 ` jungle Boogie @ 2018-08-10 17:12 ` Aaron Jones 2018-08-10 17:25 ` jungle Boogie 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jones @ 2018-08-10 17:12 UTC (permalink / raw) To: jungle Boogie; +Cc: wireguard -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/08/18 16:40, jungle Boogie wrote: > If someone already has my ssh key, I'd revoke it - regardless if > they had the password or not. Same with the WG key - shutdown the > tunnel, remove the affected peer and start it back up. No need to interrupt the tunnel. # wg set <interface> peer <publickey> remove -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAlttx3oACgkQivBzdIir MBJTWw//dL9Te/8nfr18EQQEmWXRqgS7A6QrXh5lrAjTlHAHuzbfM2sp+mt5ML50 fmEHlsVHZqM4rG4l1+KiSrUb6n7hlzoCO2bwh36U/tdysXgf20vM9XN4vyhvWMbN eOB6CNHfso02uMzx4TCAaK2ZcWnsqh1LvXceVwMQdJ6+E2FDpu637TYEiWJyIDPv u/q5Qq+qZspFiqDTpAJ/scdLq+4AxnzeELs/OblfRYbvE+Hkc9VsunxXJImXvcKx cN1NldPxwR+a4fWTvKgIqVReIKEggDl4OzYZk+wipFLRwQWASYW3aYQ+UeQEaUHa TQqkfZ6PqvivKLPC+Ih3DVHYd4Xa4t+zC/gVtQYgAauhqcqtpH1Y0ZISohIR9x/t 2GMxOZPg7Q6x05qf0bKdWPgdH+lcENW1HYEhj/cWrKaCAoKgKOnGsfgUNEdvRXMb i/RiLnJ5NH07sg4C/QRdVOXxx/TwBoEZPvgXUsxteadBc77LLOR4ERNVZ4zQrvhv JhhLeckOL9dmywPuvvO4sc/cOZCvb2kaYSDD1Tn4iJaqWZwWdA8HNnGyBnl14mMF 9ER5qzSA0L9QRDXhyBkv1+ekDmshBnpyj6PN7kBJ5cl9WVZXLjIsUWcte9YXfbIM MqwqhoGBdF0n5T41OP0zt4vT1DWLF9pGsOiUUq7GahpIXp1mPMo= =T+rR -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 17:12 ` Aaron Jones @ 2018-08-10 17:25 ` jungle Boogie 0 siblings, 0 replies; 20+ messages in thread From: jungle Boogie @ 2018-08-10 17:25 UTC (permalink / raw) To: Aaron Jones; +Cc: WireGuard mailing list > > On 10/08/18 16:40, jungle Boogie wrote: >> If someone already has my ssh key, I'd revoke it - regardless if >> they had the password or not. Same with the WG key - shutdown the >> tunnel, remove the affected peer and start it back up. > > No need to interrupt the tunnel. > > # wg set <interface> peer <publickey> remove > Dang, that's cool! That's for the info. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler ` (4 preceding siblings ...) 2018-08-10 15:03 ` Roman Mamedov @ 2018-08-10 20:15 ` em12345 2018-08-10 23:07 ` Reuben Martin 2018-08-11 19:18 ` Jason A. Donenfeld 6 siblings, 1 reply; 20+ messages in thread From: em12345 @ 2018-08-10 20:15 UTC (permalink / raw) To: wireguard Hi, > From my point of view, the only thing which makes me uncomfortable about > wireguard is the lack of any second authentication factor. Your private > key is embedded in a plaintext file in your device (e.g. laptop), not > even protected with a passphrase. Most VPN authentications are just authorizing the machine and not the user sitting in front of that machine. > Anyone who gains access to that > laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, No matter how much keys, passwords or tokens have to be entered by the user sitting in front of that machine, any other user already on that machine, will gain sooner or later access to the tunnel. This user or attacker doesn't even need to see/know wireguard's private key nor does the attacker need root access. Think of a second user logged in on that machine. It is definitely a bad idea to assume that the tunnel traffic of one "client" (in terms of wg's client key pair) comes from a specific user. Which also means that even multi factor VPN authentication still require all services inside the tunnel to ask for user authentication. Emmanuel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 20:15 ` em12345 @ 2018-08-10 23:07 ` Reuben Martin 0 siblings, 0 replies; 20+ messages in thread From: Reuben Martin @ 2018-08-10 23:07 UTC (permalink / raw) Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 1652 bytes --] On Fri, Aug 10, 2018, 3:16 PM em12345 <em12345@web.de> wrote: > Hi, > > > From my point of view, the only thing which makes me uncomfortable about > > wireguard is the lack of any second authentication factor. Your private > > key is embedded in a plaintext file in your device (e.g. laptop), not > > even protected with a passphrase. > > Most VPN authentications are just authorizing the machine and not the > user sitting in front of that machine. > > > Anyone who gains access to that > > laptop is able to establish wireguard connections. > > > > Of course, it can be argued that the laptop holds other information > > which is more valuable that the wireguard key, therefore you should > > concentrate on properly securing the laptop itself (*). Furthermore, > > No matter how much keys, passwords or tokens have to be entered by the > user sitting in front of that machine, any other user already on that > machine, will gain sooner or later access to the tunnel. This user or > attacker doesn't even need to see/know wireguard's private key nor does > the attacker need root access. Think of a second user logged in on that > machine. > > It is definitely a bad idea to assume that the tunnel traffic of one > "client" (in terms of wg's client key pair) comes from a specific user. > Which also means that even multi factor VPN authentication still require > all services inside the tunnel to ask for user authentication. > It should me noted that it is possible to isolate the VPN access to a specific user if you assign login sessions to isolated network namespaces and place the wireguard interface within the user's namespace. -Reuben > [-- Attachment #2: Type: text/html, Size: 2304 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler ` (5 preceding siblings ...) 2018-08-10 20:15 ` em12345 @ 2018-08-11 19:18 ` Jason A. Donenfeld 2018-08-11 22:52 ` Luiz Angelo Daros de Luca 6 siblings, 1 reply; 20+ messages in thread From: Jason A. Donenfeld @ 2018-08-11 19:18 UTC (permalink / raw) To: Brian Candler; +Cc: WireGuard mailing list On Fri, Aug 10, 2018 at 6:35 AM Brian Candler <b.candler@pobox.com> wrote: > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection I think that given the WireGuard building block, it's certainly possible to build a 2FA framework around it. And I do generally like 2FA and short-lived credentials and such. Probably after getting the implementations buttoned up -- kernel mainline, windows, etc -- I'll turn a bit of attention to expanding tooling and full packages around the simple wg0 interface. Jason ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-11 19:18 ` Jason A. Donenfeld @ 2018-08-11 22:52 ` Luiz Angelo Daros de Luca 2018-08-12 0:15 ` Aaron Jones 0 siblings, 1 reply; 20+ messages in thread From: Luiz Angelo Daros de Luca @ 2018-08-11 22:52 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list, Brian Candler [-- Attachment #1: Type: text/plain, Size: 374 bytes --] > I think that given the WireGuard building block, it's certainly > possible to build a 2FA framework around it. > I see these wireguard extra features just like dhcp is. Nobody thinks about implementing dhcp inside kernel or even iproute tools. +1 for 2FA and +1 for a service that share peer info, allowing a mesh vpn > -- Luiz Angelo Daros de Luca luizluca@gmail.com [-- Attachment #2: Type: text/html, Size: 892 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-11 22:52 ` Luiz Angelo Daros de Luca @ 2018-08-12 0:15 ` Aaron Jones 2018-08-12 0:46 ` Jason A. Donenfeld 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jones @ 2018-08-12 0:15 UTC (permalink / raw) To: Luiz Angelo Daros de Luca; +Cc: WireGuard mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote: > I see these wireguard extra features just like dhcp is. Nobody > thinks about implementing dhcp inside kernel or even iproute > tools. The Linux kernel has a (minimal, non-configurable) DHCP client already (used for rootfs on NFS without an initramfs, among other things). CONFIG_IP_PNP_BOOTP=y -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF 45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34 gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz 3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh 5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ 9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc= =OY67 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-12 0:15 ` Aaron Jones @ 2018-08-12 0:46 ` Jason A. Donenfeld 2018-08-12 1:07 ` Aaron Jones 0 siblings, 1 reply; 20+ messages in thread From: Jason A. Donenfeld @ 2018-08-12 0:46 UTC (permalink / raw) To: A Jones; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 1721 bytes --] On Sat, Aug 11, 2018, 17:15 Aaron Jones <aaronmdjones@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote: > > I see these wireguard extra features just like dhcp is. Nobody > > thinks about implementing dhcp inside kernel or even iproute > > tools. > > The Linux kernel has a (minimal, non-configurable) DHCP client already > (used for rootfs on NFS without an initramfs, among other things). > > CONFIG_IP_PNP_BOOTP=y > This is in fact true, but I'm not sure we're planning on following suite with that kind of thing in kernel space for WireGuard... > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir > MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF > 45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl > LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq > WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm > zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK > uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34 > gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz > 3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh > 5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ > 9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y > CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc= > =OY67 > -----END PGP SIGNATURE----- > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > [-- Attachment #2: Type: text/html, Size: 2670 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-12 0:46 ` Jason A. Donenfeld @ 2018-08-12 1:07 ` Aaron Jones 0 siblings, 0 replies; 20+ messages in thread From: Aaron Jones @ 2018-08-12 1:07 UTC (permalink / raw) To: Jason; +Cc: WireGuard mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/08/18 00:46, Jason A. Donenfeld wrote: > This is in fact true, but I'm not sure we're planning on following > suite with that kind of thing in kernel space for WireGuard... Indeed. :) -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltviFMACgkQivBzdIir MBIolg//Tbt8zZy/nqtY3njasE6n5OXGs/qSP2GZbJSB4Ieyi1TZfJRumJTNfKSM YLHZmaju+KZO85f6fwj+wqe89swD6WD0mGPKpCwhc+3j403YyT/ggp9uyqSTP78H D9KEIFnX50mtwnj6cWzY3U9H3V0katWRms0P65U90kJF1Fb91EeAplIZnHlIygwa m9+lBB8oJ+dXgkNmjaajI23idYV1qFVw8z9TR22lyXjAWsK0evJ1rcpKtuiIn9FX 3eZ+0QBNF5lCDVyWKl8Y04rattFde3jWs9AAzDPP4nv8GJqo9Jpponzy8jXSFxu5 CwvDShMS3ytWIO+zmSskkcZmh7h00puDhLzVRXneTfE7kbIyT31xQsH4sS2LQ4cY 4W3RoIYY7DnJW1IEaUYa3FAVWjW7XNZUUAU0fNcYJHVmqrPtDJYm692OEv8Hou3+ yn2YjaXaQPXPFqztLrExqDQL2RS4evSx0TRgTBp39ya43MDILM+EG3j04G4ibuyV EeDykMd6KY3h3fVsxhQBE0lryDgS2QHZsr+6ziwFzP8e0Pmy6vU32iNEw1MhEItX 4ffufoanwXO7UKPpcoHCZDOzcxbo7DUDt4EEQpLYSOr4fXqcHfxY6dhT1vetRA0U rnVnX2/tkrDUKJcUI8d7DV1WJqQQUBWdNLzZXWuYcAE08U74U+I= =4Yzj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Reflections on WireGuard Design Goals @ 2018-08-09 21:52 Jason A. Donenfeld 2018-08-10 15:19 ` nicolas prochazka 0 siblings, 1 reply; 20+ messages in thread From: Jason A. Donenfeld @ 2018-08-09 21:52 UTC (permalink / raw) To: WireGuard mailing list Hey list, For whatever reason, in the last several weeks, WireGuard been receiving a considerable amount of attention, and with that comes various parties interested in the project moving in this direction or in that direction. An= d more generally, over the last year or so, we've seen a decent amount of interest from different folks wanting to do different things with the proje= ct and with the protocol. This inevitably leads to the question: what do we actually want WireGuard to be, as a project, as a protocol, as a set of implementations, as a design methodology, and so forth? I've had a pretty clear idea about that, but I don't think I've ever tried to communicate aspects of it in this context, so I thought here I'd highlight two importan= t design goals that motivate us. Firstly, WireGuard intends on continuing to have a minimal core, without a = lot of options and wild features and support for weird networking paradigms. Su= re, we want the core to be sufficiently flexible that you can build interesting and complex things on top of it, but we don't want WireGuard itself to be complicated. We enjoy our small understandable configuration files, an interface that appears to be mostly stateless, and general ease of use. Eve= n from a cryptography and implementation perspective, the protocol is designe= d to be implementable using simple algorithms and coding techniques. With that kind of minimalism naturally comes the temptation to add things. Simply from the perspective of an interested engineer, it's appealing to extend and hack on small manageable codebases and projects, since adding a single feature here or there just isn't that hard. And after all, if you're *just* adding *one* feature, it's only one, and that's not so bad, right? A= nd what about one more? This kind of temptation applies equally to features inside implementations as it does to features inside the protocol. And I th= ink this temptation is a little bit dangerous, both because it's an obvious slippery slope to bloat ("just one more feature can't hurt, right guys?"), = and because while individual features or protocol enhancements might be well thought-out, it's often hard to think through them in the context of a full= er system. Secondly, WireGuard is engineered slowly and carefully. It is a conservativ= e project. Programming is fun, and so I understand the appeal to, "move fast = and break things," or to ship new code hastily. Personally I've written plenty = of such codebases, and that's usually fun and exciting. Except WireGuard is deeply security-oriented. Of course there will inevitably be scary bugs we weren't able to prevent, but we're moving slow and carefully to try to mitigate those to the fullest extent we can. We want each of the implementations released by the WireGuard project to be secure, high assura= nce software. This means that although you can probably get something mostly "working" in= a fairly short amount of time (an initial version of WireGuard took me essentially a weekend), we're trying very hard not to throw junk over the fence. Rather, we're doing pretty regular code reviews and have received so= me great feedback from some scary-talented security researchers, and we expect for this to continue. But indeed not all programmers share this perspective= =E2=80=93 for a wide variety of motivations, both benign and opportunistic =E2=80=93 = and so we definitely will (and have, in fact, already) see folks making things relate= d to WireGuard who don't share this type of methodology. Now I don't think these two motivating principles are particularly unique o= r innovative. Other security-focused projects, like OpenBSD for example, seem= to be made of a somewhat similar mold. But these also certainly are not the _norm_ for most projects out there. And as WireGuard accelerates in usage, = I expect we'll be facing this from a few angles: - Attempts at commercialization: There are many businesses who want to embr= ace WireGuard and extend it in some particular direction or another, in order= to build products or sell services or the usual array of business opportunities. Engineers working in these contexts often times are tempte= d to extend minimal things in grotesque ways, and to push them to market wi= th deadlines unfavorable to high assurance methodologies. It's naturally and understandably in the interest of businesses to attempt to steer the WireGuard project in directions aligned with their goals, or even directl= y hire WireGuard developers away from an independent perspective working on the open source project. This is pretty commonplace with open source projects, and while sometimes everyone's interests align perfectly, it's easy to loose sight of the broader project goal; in particular, the goal = of minimalism in particular is easy to leave by the wayside. - Folks who want their own corner of the Internet: We've already seen this with a project, and as things accelerate, we'll probably also see it with others. It's fun to run a project, and some people want to start with WireGuard (and even our webpage design) but then spin it into all sorts o= f new clever and creative things, extending the protocol, adding features, shipping code hastily, with the explicit caveat of not working within the WireGuard project or sticking with our design goals. Some folks simply aren't interested in joining community projects. While I understand the f= un and motivation of having your own corner, depending on the scale, I think ultimately it's harmful to users and harmful to the project as a whole. I also understand that splintering projects might aid in creating commercia= l opportunities too, but again, I think it is overall harmful to the ecosystem, whether open source or proprietary. I should mention that The WireGuard project remains open to all sorts of development and developers who would like to join in, in any capacity, and indeed we're quite eager = to continue to share or hand off maintenance burden to others. We're also willing and interested to work hand-in-hand with other open source projec= ts that share our design goals and methodologies. - The N+1 protocol: https://xkcd.com/927/ might just be a part of life. I expect we'll be seeing a proliferation of Noise-based VPN protocols, tailored for different use cases and environments, with differing securit= y properties and attack surfaces. Designing protocols always involves trade-offs, and there are always interesting arguments for different trade-offs, and I wouldn't be surprised if we see some more WireGuard-lik= e things come out. Perhaps someday down the line after years of observation= , there will even be improvements made for a new WireGuard protocol, incorporating the rejuvenated research that's now being put into these ty= pes of settings. Or not. But maybe. But either way, it seems likely there wil= l be various N+1 protocol proposals and implementations, because people apparently like to make things; see XKCD. So, if WireGuard remains a small niche project, we'll keep on keeping on quietly and surely as ever. But should things continue to grow in usage as we're seeing now, expect to see the various temptations proliferate. But regardless, I certainly intend to keep WireGuard true to our design goals = =E2=80=93 of minimalism, of security conservatism =E2=80=93 and I'll be working hard to = see that through. I should also reiterate that our doors remain very open to open source developers and projects who wish to join the work we're doing. Regards, Jason ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Reflections on WireGuard Design Goals 2018-08-09 21:52 Jason A. Donenfeld @ 2018-08-10 15:19 ` nicolas prochazka 0 siblings, 0 replies; 20+ messages in thread From: nicolas prochazka @ 2018-08-10 15:19 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list hello, just to say you, as a simple end user we are using wireguard since one year for our product, we have 10K tunnels deployed , wireguard is perfect for us, very simple, we can develop our specific code on top of if ( key management , ....) so +1 for jason vision thanks for this piece of code Regards, Nicolas Le jeu. 9 ao=C3=BBt 2018 =C3=A0 23:52, Jason A. Donenfeld <Jason@zx2c4.com>= a =C3=A9crit : > > Hey list, > > For whatever reason, in the last several weeks, WireGuard been receiving = a > considerable amount of attention, and with that comes various parties > interested in the project moving in this direction or in that direction. = And > more generally, over the last year or so, we've seen a decent amount of > interest from different folks wanting to do different things with the pro= ject > and with the protocol. This inevitably leads to the question: what do we > actually want WireGuard to be, as a project, as a protocol, as a set of > implementations, as a design methodology, and so forth? I've had a pretty > clear idea about that, but I don't think I've ever tried to communicate > aspects of it in this context, so I thought here I'd highlight two import= ant > design goals that motivate us. > > Firstly, WireGuard intends on continuing to have a minimal core, without = a lot > of options and wild features and support for weird networking paradigms. = Sure, > we want the core to be sufficiently flexible that you can build interesti= ng > and complex things on top of it, but we don't want WireGuard itself to be > complicated. We enjoy our small understandable configuration files, an > interface that appears to be mostly stateless, and general ease of use. E= ven > from a cryptography and implementation perspective, the protocol is desig= ned > to be implementable using simple algorithms and coding techniques. > > With that kind of minimalism naturally comes the temptation to add things= . > Simply from the perspective of an interested engineer, it's appealing to > extend and hack on small manageable codebases and projects, since adding = a > single feature here or there just isn't that hard. And after all, if you'= re > *just* adding *one* feature, it's only one, and that's not so bad, right?= And > what about one more? This kind of temptation applies equally to features > inside implementations as it does to features inside the protocol. And I = think > this temptation is a little bit dangerous, both because it's an obvious > slippery slope to bloat ("just one more feature can't hurt, right guys?")= , and > because while individual features or protocol enhancements might be well > thought-out, it's often hard to think through them in the context of a fu= ller > system. > > Secondly, WireGuard is engineered slowly and carefully. It is a conservat= ive > project. Programming is fun, and so I understand the appeal to, "move fas= t and > break things," or to ship new code hastily. Personally I've written plent= y of > such codebases, and that's usually fun and exciting. Except WireGuard is > deeply security-oriented. Of course there will inevitably be scary bugs w= e > weren't able to prevent, but we're moving slow and carefully to try to > mitigate those to the fullest extent we can. We want each of the > implementations released by the WireGuard project to be secure, high assu= rance > software. > > This means that although you can probably get something mostly "working" = in a > fairly short amount of time (an initial version of WireGuard took me > essentially a weekend), we're trying very hard not to throw junk over the > fence. Rather, we're doing pretty regular code reviews and have received = some > great feedback from some scary-talented security researchers, and we expe= ct > for this to continue. But indeed not all programmers share this perspecti= ve =E2=80=93 > for a wide variety of motivations, both benign and opportunistic =E2=80= =93 and so we > definitely will (and have, in fact, already) see folks making things rela= ted > to WireGuard who don't share this type of methodology. > > Now I don't think these two motivating principles are particularly unique= or > innovative. Other security-focused projects, like OpenBSD for example, se= em to > be made of a somewhat similar mold. But these also certainly are not the > _norm_ for most projects out there. And as WireGuard accelerates in usage= , I > expect we'll be facing this from a few angles: > > - Attempts at commercialization: There are many businesses who want to em= brace > WireGuard and extend it in some particular direction or another, in ord= er to > build products or sell services or the usual array of business > opportunities. Engineers working in these contexts often times are temp= ted > to extend minimal things in grotesque ways, and to push them to market = with > deadlines unfavorable to high assurance methodologies. It's naturally a= nd > understandably in the interest of businesses to attempt to steer the > WireGuard project in directions aligned with their goals, or even direc= tly > hire WireGuard developers away from an independent perspective working = on > the open source project. This is pretty commonplace with open source > projects, and while sometimes everyone's interests align perfectly, it'= s > easy to loose sight of the broader project goal; in particular, the goa= l of > minimalism in particular is easy to leave by the wayside. > > - Folks who want their own corner of the Internet: We've already seen thi= s > with a project, and as things accelerate, we'll probably also see it wi= th > others. It's fun to run a project, and some people want to start with > WireGuard (and even our webpage design) but then spin it into all sorts= of > new clever and creative things, extending the protocol, adding features= , > shipping code hastily, with the explicit caveat of not working within t= he > WireGuard project or sticking with our design goals. Some folks simply > aren't interested in joining community projects. While I understand the= fun > and motivation of having your own corner, depending on the scale, I thi= nk > ultimately it's harmful to users and harmful to the project as a whole.= I > also understand that splintering projects might aid in creating commerc= ial > opportunities too, but again, I think it is overall harmful to the > ecosystem, whether open source or proprietary. I should mention that T= he > WireGuard project remains open to all sorts of development and develope= rs > who would like to join in, in any capacity, and indeed we're quite eage= r to > continue to share or hand off maintenance burden to others. We're also > willing and interested to work hand-in-hand with other open source proj= ects > that share our design goals and methodologies. > > - The N+1 protocol: https://xkcd.com/927/ might just be a part of life. I > expect we'll be seeing a proliferation of Noise-based VPN protocols, > tailored for different use cases and environments, with differing secur= ity > properties and attack surfaces. Designing protocols always involves > trade-offs, and there are always interesting arguments for different > trade-offs, and I wouldn't be surprised if we see some more WireGuard-l= ike > things come out. Perhaps someday down the line after years of observati= on, > there will even be improvements made for a new WireGuard protocol, > incorporating the rejuvenated research that's now being put into these = types > of settings. Or not. But maybe. But either way, it seems likely there w= ill > be various N+1 protocol proposals and implementations, because people > apparently like to make things; see XKCD. > > So, if WireGuard remains a small niche project, we'll keep on keeping on > quietly and surely as ever. But should things continue to grow in usage a= s > we're seeing now, expect to see the various temptations proliferate. But > regardless, I certainly intend to keep WireGuard true to our design goals= =E2=80=93 of > minimalism, of security conservatism =E2=80=93 and I'll be working hard t= o see that > through. > > I should also reiterate that our doors remain very open to open source > developers and projects who wish to join the work we're doing. > > Regards, > Jason > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-08-12 0:56 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.1318.1533866648.2201.wireguard@lists.zx2c4.com> 2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler 2018-08-10 14:09 ` Matthias Urlichs 2018-08-10 14:09 ` Kalin KOZHUHAROV 2018-08-10 14:42 ` Eisfunke 2018-08-10 14:47 ` Konstantin Ryabitsev 2018-08-10 15:03 ` Roman Mamedov 2018-08-10 16:03 ` Brian Candler 2018-08-10 16:38 ` Kalin KOZHUHAROV 2018-08-10 16:40 ` jungle Boogie 2018-08-10 17:12 ` Aaron Jones 2018-08-10 17:25 ` jungle Boogie 2018-08-10 20:15 ` em12345 2018-08-10 23:07 ` Reuben Martin 2018-08-11 19:18 ` Jason A. Donenfeld 2018-08-11 22:52 ` Luiz Angelo Daros de Luca 2018-08-12 0:15 ` Aaron Jones 2018-08-12 0:46 ` Jason A. Donenfeld 2018-08-12 1:07 ` Aaron Jones 2018-08-09 21:52 Jason A. Donenfeld 2018-08-10 15:19 ` nicolas prochazka
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 NNTP newsgroup(s).