IrcMeetings

Basic info

  • Time: Wednesday 30 October 2024 at 14:00 CEST (12:00 UTC)
  • Place: #openvpn-meeting channel on LiberaChat IRC network

Topics

Current topics

  • Updated: DCO and Linux upstreaming, API change
    Upstreaming DCO to Linux is proceeding, it is in review stage at the moment.
    ordex sent in patchset version 11. Awaiting feedback.

  • Updated: DCO windows multi-peer
    Kernel-side stuff looks to be mostly done. Currently look into user-space stuff and some proper locking and memory management (refcounters etc).

  • Updated: multi-socket patch series
    4 preparation work patches were merged. Now it's on to the real patch series.

  • Updated: data format v3 / epoch data keys
    plaisthos has written a new draft for new key handling for the data channel based on discussions in Karlsruhe.
    See https://github.com/OpenVPN/openvpn-rfc/pull/5.
    The current state is that the work for it is done but not yet sent in - plaisthos indicates he wants to test and implement it with openvpn3 before submitting it to openvpn2.

  • buildbot improvements
    cron2 requests that we pretty please have a mingw build in gerrit. djpig indicates next week should be possible.
    mattock has a patch to split the mails for different project to different mail addresses. The idea is to split openvpn3 and openvpn3-linux out so it doesn't go to openvpn-builds@ ML anymore.
    Instead we could create a openvpn3-builds@ ML. djpig will look into that.

  • push_update / live route updates
    There were some clarification questions which resulted in the decision we should add a few clarifying words to the RFC.
    Implementation for OpenVPN v2 will be looked at by ordex and his team.

  • where next community meeting
    Italy or Spain have been mentioned.
    Beer: yes.
    T-shirts: yes.

  • t_server_null improvements
    The tests against latest git master server against older openvpn client versions are almost done.

  • Release 2.7
    ../../Development/StatusOfOpenvpn27 was updated with the results from Karlsruhe meetup.
    compare wiki:CommunityMeetup2024.
    Note: automatic enabling of --compression migrate was dropped from feature list since djpig discovered it is too complicated to get right.

  • 2.7 security audit
    ordex mentioned that OTF offers the possibility to get a 3rd-party security audit for supported projects. So we will apply for that around or after the 2.7 release to review the latest code.

Backlog

  • --dns patch review upcoming
    DNS patches were discussed during Meetup. d12fk will provide them for review real soon.

  • community.openvpn.net trac wiki
    Seems mattock managed to get it into a reasonable shape ready for production.
    Some required changes to otterwiki have been submitted upstream.
    Next step is looking at migrating data from old to new.
    Also djpig needs to provide an EC2 instance in the community account for hosting production.

  • forums topics
    novaflash has access and is working on a PoC setup combining old and new on an ubuntu server.

  • Tunnelcrack progress
    Status update on TunnelCrack mitigations:
    The tunnelcrack mitigation for Windows has gone in master, which will go to 2.7 release. There is the possibility for it to go to 2.6.x if we can find testers for this.
    Windows, openvpn2: merged to master, not to 2.6.x. openvpn3: in code review.
    Linux, openvpn2: in progress. openvpn3: in progress.
    macOS: to be determined.
    iOS: to be determined.
    Android: not vulnerable.

  • run tests of 2.x against openvpn3? how?
    There is a 'null client' variant of ovpncli that allows to make VPN connections but not fully, for testing purposes.
    This is in the openvpn3 repository.

  • donation collection
    From earlier exploration it is clear that setting up a legal entity is not worth the expense at this point. We're just starting out with donations.
    What we can do is start out with an existing company that can collect the money and puts it to good community use. ordex volunteers to take this on.
    There are some options to consider. There may be existing solutions that we want to consider.
    PayPal seems overly expensive with all their fees.
    Stripe could be worth considering for credit card processing.
    GitHub Sponsors was mentioned as a possible solution, this is worth investigating.
    Open Collective was also mentioned, that needs some investigating how that exactly would work for us.

  • Community AWS account governance
    Currently the Community AWS account is part of the OpenVPN, Inc. AWS organization
    With the OTF founding there would be opportunity to move to a separate AWS account that is not under the corporate umbrella.
    Requires further discussion whether that is something we want.

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

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

  • Static-key mini how-to is outdated.
    This page is outdated badly: https://openvpn.net/community-resources/static-key-mini-howto/
    company will send this to tech writer to redo based on https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/example-fingerprint.rst info and also retain a link to that github doc.
    having a simple guide online will help adoption

  • 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?
    matt provided icons in https://github.com/OpenVPN/openvpn-gui/issues/595
    last update: will be picked up by selva when he has time

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

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