wiki:Topics-2024-04-03

IrcMeetings

Basic info

  • Time: Wednesday 3 April 2024 at 13:00 CEST (11:00 UTC)
  • Place: #openvpn-meeting channel on LiberaChat IRC network

Topics

Current topics

  • New: live route update feature
    A client implementation will be added to OpenVPN3 core soonish.
    Obviously we'll need a spec that can be agreed on for this feature.
    And ideally also an openvpn2 implementation (client+server).
    lev will put together a spec proposal for next meeting.
  • Updated: website release process
    Waiting for faster way to update community downloads and security advisories on main site.
    Again postponed due to issues. Now planned for this week. We'll see.
  • Updated: forums topics
    ecrist still working on forums. a DNS record for the future archive address will be added, rob0 is doing this.
    Plan is to soon switch URLs so new forum is on forums.openvpn.net and old forums is on archive address.
    - email confirmation on registration was suggested.
    - we still need to work on having some other people with some admin or high mod access.
    - mod guide, hard or soft delete (chuck board?), what to do with GDPR, etc. (write it down and actually make it available to mods, maybe a hidden topic)
    - access for mods to logs so one can see what others did
  • Updated: mattock topics
    Separated test data from code in --dev null tests.
    Also started on debian snapshot publishing but didn't get very far there yet.
    Will next look at remove sudo root requirement from --dev null server-side.
    Figure out if reliability can be increased further (i.e. why did it fail 4 out of 500 times).
  • Closed: when to deprecate weak ciphers
    Weak ciphers like 3DES and BF-CBC - what to do with them and when?
    Originally it looks like it was planned to remove in 2.7 but that may be too soon.
    For example OpenVPN Inc. still sees customers with 10+ year old installations fairly regularly.
    A proposal to consider may be to deprecate it when crypto libraries deprecate it.
    Weighing the expected complaints versus the low cost of just maintaining weak ciphers until crypto libraries deprecate them - the choice seems obvious.
    For now we'll stick with letting weak ciphers stay in unless there is some convincing reason to remove it.
  • DCO and Linux upstreaming, API change
    Upstreaming DCO to Linux is proceeding, it is in review stage at the moment.
    ordex will prepare a v3 patchset soon based on feedback received.
    There will be an API change that makes it incompatible with the current implementation.
    A graceful solution to that was already discussed and in motion. giaan will be working on this.
    (in a nutshell, make OpenVPN understand old and new API, DKMS and kernel versions both will then use new API, then we drop old API)
  • Security mailing list procedure can stand improvement
    dazo and novaflash will start discussing this internally in openvpn inc.
    Goal of discussions is to work out a better internal procedure to connect security mailing list better with company product responsible people.
  • donation collection
    ordex consulted an expert and it looks like doing a legal entity does not make sense when you're just starting out.
    The tricky part here is that only if we get a lot of donations and a lot of money does it make sense to have that kind of overhead.
    What we can do is start out with a company that collects the money and puts it to good community use. ordex volunteers to take this on.
    We want the donations to be collected in one place, and expenses made from that one place, so we are accountable.
    We need to figure out how to deal with that legally, and what payment methods to accept and how.
    Probably credit card is a must. Maybe paypal as well. Bitcoin seems to encounter some resistance in the discussions.
    And a reminder; we definitely do not want the donation thing to be forced - have a mechanism to do it, but keep it out of the way.
  • Status of SBOM
    There was a discussion between MaxF and djpig and others.
    For OpenVPN2 / OpenVPN-NL, there is not much overlap, as OpenVPN2 doesn't ship much in terms of libraries, but OpenVPN-NL does.
    The interesting use-case for an SBOM is really the OpenVPN Windows GUI client.
  • status of trac/wiki
    No progress since last meeting.
    This will probably have to wait until "--dev null" is done
    Should have access controls so only approved members can edit.
  • OpenVPN community meetup 2024
    Naming: We decided to rename from 'Hackathon' to 'OpenVPN community meetup'. This has a more open spirit to it, as we want to encourage developers and those interested in contributing to feel welcome.
    Where: Karlsruhe, Germany. It is a relatively central location in Europe and is fairly easily reachable by train. A meeting location is yet to be arranged.
    When: At the moment tentatively set to 20-22 September 2024.
    Who: We'll do an open invitation to openvpn-devel mailing list, but also CC: specifically past attendees and people of interest.
    Shirts: There is plenty of time still to prepare a shirt design.
  • OpenVPN 2.6 performance results.
    tests should cover: gre, ipsec, userland, dco
    linux, freebsd, windows
    requires time to be dedicated to doing this, when time available will do it
  • software code signing topic
    company switched EV code signing to cloudhsm, this is same cert type we use for driver signing, is also suitable for binary signing.
    in future we could possibly switch community to that same key. saves having to maintain 2 different keys.
    depends on how hard/easy it is to access company key signing thingee from community infrastructure.
    also no high priority at the moment, we have a working solution now.
  • Management interface documentation on main website will be updated with info from doc/management-notes.txt
    novaflash will pick this up at some point

Mattock topics

--dev null server testing

Mattock has improved so-called "--dev null server testing" and integrated it with "make check". The features are:

  • Does what it says on the tin
  • Mostly operating-system agnostic
  • Should be POSIX shell compliant but uses Bash now
  • Uses the sample certificates and keys
  • Supports running directly as root and with sudo
  • Supports using different OpenVPN client versions
    • The "current" (just compiled) version
    • Any other OpenVPN versions (must be present on the filesystem)
  • Support testing for success as well as failure
  • Test cases (client configurations) and server setups (server configurations) are stored in a configuration file, i.e. data and code have been separated
  • Configuration file format is nearly identical to t_client.rc configuration

Here's how it works:

  1. make check
    1. t_server_null.sh
      1. t_server_null_server.sh
        • Launches the compiled OpenVPN server instances as root (if necessary with sudo)
        • OpenVPN servers exit when all clients have disconnected from all servers
      2. t_server_null_client.sh
        • Launches each individual client test
        • Client kills itself after some delay using an "--up" script

Current PoC code is available in mattock's "dev_null" branch. A good starting point is ​t_server_null.sh.

Mattock is improving test success rates now. When servers (due to a bug) did not exit in between stress tests reliability was 100%. However. with that bug fixed, best reliability so far was 99%. As normal "make check" will involve spinning up new servers, the 99% reliability number is the number we should be looking at. It seems that the connection failures are caused by clients which try to connect to a server that is not yet up and/or when it is no longer running. Better synchronization between clients and servers is needed. Checking for presence of server pid files may or may not help there.

Debian/Ubuntu snapshot publishing

  • In the last meeting we agreed to publish snapshot Debian/Ubuntu packages on *build.openvpn.net*
  • The tool to use to publish is ​aptly
  • aptly does not have direct support for running commands (e.g. rsync, scp) after publishing packages, e.g. to a local filesystem on the buildmaster
    • Option 1 (hacky): use inotifywait with rsync or scp to copy the published repo to build.openvpn.net
    • Option 2 (less hacky): use NFS to publish "directly" to build.openvpn.net
    • Both options require a fair amount of tinkering
  • Mattock moved this forward a bit at the buildbot end (get the files out from workers)
Last modified 3 weeks ago Last modified on 04/10/24 16:24:53