Changes between Version 40 and Version 41 of KarlsruheHackathon2017


Ignore:
Timestamp:
11/12/17 10:30:27 (6 years ago)
Author:
Steffan Karger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • KarlsruheHackathon2017

    v40 v41  
    114114  * Considered if callers of the argv_*() functions should be enforced to provide a gc_arena.  Decided such a change would be quite intrusive and not providing any clear gains.  The argv_*() functions already have an internal gc_arena which is used for the argv arrays of string pointers and is handled properly there.  Where memory is allocated by argv_*() functions to be returned to the calling function, a gc_arena pointer is already provided in that call; that allocation happens in the gc_arena owned by the caller.  This provides a clear separation between internal processing and callers.
    115115  * Will also try to add a bit more code comments to ensure the code is easier to understand in the future
     116
     117 * Version life cycle
     118   * Agreed that our current approach is quite good, but poorly documented and communicated.
     119   * David and Steffan wrote a draft that should help change that, comments and contributions very welcome: https://community.openvpn.net/openvpn/wiki/SupportedVersions
     120   * We will aim for having all 2.5 features in for the 2018 hackathon, and go into 'produce a release mode' afterwards.
     121     * tls-crypt-v2
     122     * transport plugin (primary use case: obfuscation)
     123     * netlink support (includes route.c / tun.c refactoring)
     124     * 'make VPN fast again!'
     125     * remove ENABLE_CRYPTO
     126     * purge NSIS installers (migrate to MSI installers)
     127     * improve control channel performance
     128     * update the PRF to ditch MD5/SHA1 (not because broken crypto (it is not!), but for simplicity and marketing)
     129     * maybe: add PRF plugin interface
     130     * maybe: add key exchange plugin interface (allows easily doing .e.g post quantum kex)
     131     * maybe: add data channel separation (or, move to ovpn3, which already has this?)