Home A - Z
Page Index

An Otter Wiki

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 a faster way to update community downloads and security advisories on the 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.
    • The goal of discussions is to work out a better internal procedure to connect the 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 the last meeting.
    • This will probably have to wait until "--dev null" is done
    • Should have access controls so only approved members can edit.

  • Tunnelcrack progress TunnelCrack community wiki article

    • Current status: when mitigations start appearing we will mention them in meeting notes.

  • 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 the 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.

  • Static-key mini how-to is outdated.

  • 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

  • What's going on with new taskbar icons?

  • Software code signing topic

    • The company switched EV code signing to cloudhsm, this is the same cert type we use for driver signing, is also suitable for binary signing.
    • In the future, we could possibly switch the community to that same key. Saves having to maintain 2 different keys.
    • Depends on how hard/easy it is to access the company key signing thing from community infrastructure.
    • Also, no high priority at the moment, we have a working solution now.

  • Management interface documentation on the 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
        • The 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, the 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 who 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 the 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).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9