| | 106 | * mattock: timeline for releasing a git repo of 3? james: "I'll publish a git repo in the next few weeks", it's a good time, the code has been fairly quietly recently |
| | 107 | |
| | 108 | * plan for the technical development of 2.4 and 3? |
| | 109 | * "we will have 2.x around for quite a while, at least for the server" |
| | 110 | * 3 will eventually be "a general client", and we might remove "client-only bits" from 2.x |
| | 111 | * move over to 3 will take a while... |
| | 112 | * dazo: linux, network manager, talking to openvpn 3 as a client would be a great thing - james: that's what the 3 core is good at, being API driven |
| | 113 | * james: openvpn 3 is really meant to be used as a library, not so much as a command line client (even if it exists) |
| | 114 | * 2.4: d12fk: the interactive service should be in. It's being shipped in the Astaro UTM provided client for a while, and works good for IPv4 routes today, but some bits are still being added (DNS, winbind, IPv6, ...) |
| | 115 | * 2.4: dual stack cleanup (plaisthos) |
| | 116 | * behaviour about as openvpn 3 does regarding talk to dual-stack servers |
| | 117 | * well-tested in the android client, still needs review |
| | 118 | * as a side note: socket.c in 3 replaced by boost ASIO library "which is brilliant and bug free" |
| | 119 | * 2.4: handshake crypto parameters? |
| | 120 | * "what is the best way to go there"? |
| | 121 | * we have TLS handshaking - use that to define data-link cipher? |
| | 122 | * reason for independent TLS and data layer crypto: SSL library might not expose symmetric crypto algorithms that are used for SSL/TLS handshake inside the library |
| | 123 | * client pushes list of supported ciphers+hmac digest, server picks, pushes back? |
| | 124 | * GOAL: reduce extent of incompatibilities in config file settings ("1000 clients that use MD5 and you want to switch to SHA2 on the server side") |
| | 125 | * for //compression// handshake: client sends "flags" (IV_LZO=1, IV_SNAPPY=1, ...) in the TLS control channel (at authentication phase), server decides via mgmt interface or client-connect script |
