2026-10-19 08:27:46Heiko Hund:
added meeting notes from cryptpad
Meetups/2026-Paderborn.md ..
@@ 65,3 65,208 @@
Sunday 18/10:
## Meeting notes
+
+
1. Gert: 2.8 release planning
+
1. Gert wants to release 2.8 sooner, compared to older releases, because the code diverged a lot already from 2.7 and backporting patches is beginning to be annoying.
+
+
2. ideally 2.8 can be released early 2027 (february), on time for the next stable Debian release
+
+
3. 2.8 would be a cleanup release, with a few new features
+
+
4. SHOULD HAVE ("patches need to be in gerrit in the next few weeks"):
+
1. TLS cleanups (Arne)
+
+
2. string and integer cleanups (Frank)
+
+
3. server probe (Lev)
+
+
4. windows cleanup: remove network interface code from openvpn.exe (Heiko), split up monolithic iservice code into smaller compile units (Heiko), merge openvpnserv2 code back to iservice (Heiko/Lev/Gert). Please do not break debuggability ("press F5 from IDE") - "openvpn.exe --pretend-to-be-gui-talk-to-iservice-yourself"
+
+
5. remove --static (Arne? Antonio? Steffan?)
+
+
6. Push-Update and Iroutes support for DCO (needs review)
+
+
7. DCO capability negotiation (on gerrit already) - userspace can query kernel (tx-peer-id, epoch)
+
+
8. windows installer: stop building x86 installers (Lev: check microsoft telemetry if they give us numbers on 32/64 bit distribution) - Win11 only exists as 64bit version, so this would only affect win10/x86 and older versions.
+
+
9. release notes for 2.8 must contain a list of features that "will not survive in the long term" (so \*we\* need to agree on this first...)
+
+
10. deprecate / remove "small block" cipher support for real? 3DES, blowfish? -> drop support, except if you add \`--really-really-insecure-I-will-change-this-soon\` shame flag? (Arne)
+
+
5. NICE TO HAVE;
+
1. Modernize Windows installer
+
1. Upgrade WiX
+
2. Replace JScript with CMake (there is PR already from Frank)
+
2. Multisocket support for dco-win
+
+
3. TCP server support for dco-win
+
4. improved VRF support for FreeBSD (Gert) and Linux (patches in Gerrit)
+
5. multi-pool patchset from Antonio
+
6. all features should be in before christmas 2026, so we can release in february
+
+
7. Features that might not make it (from the list agreed upon in Naples)
+
1. full multipeer server-to-server etc.
+
2. pluggable transport API - "it's a bit large, and has not seen much use" - Gianmarco has kept it updated, so it's "just a matter of doing it" (-> Antonio/Gianmarco: please ping Arne) - there is a use case for "have it in master for the client side" (OpenVPN for Android), which would give more experience
+
+
3. "peer session restoring" (upgrade userspace while kernel space is keeping the tunnel active, and reattach to kernel peer)
+
+
4. route monitoring to make openvpn react to "changes in network attachment" (wifi/wired roaming, etc.) in a more nice way than "time out and reconnect"
+
+
5. user space DCO (Antonio has this all running...?)
+
+
6. "ip rule" based VPN setup on Linux (nobody working on this right now, no patch set to review)
+
+
2. \- Yuriy: Gerrit private instance setup?
+
1. "yes, please" :-)
+
+
2. Gert ("whoever pushes to the normal public repos") is responsible for pushing "public" master + release/X branches to the "private" instance as well, so push-to-private has the correct commits to base on
+
+
3. Arne: FOOD!
+
1. Steak house is out -> plan with the "ghetto Norma fusion asian place" instead (13:00)
+
2. reservation for Saturday night is "italian place" (20:00, [https://maps.app.goo.gl/yqtSCdQK7nmuXwFK8](https://maps.app.goo.gl/yqtSCdQK7nmuXwFK8))
+
+
3. Sunday lunch:
+
+
4. Sunday evening: Steakhouse
+
+
4. Frank: Release Management
+
1. Gert: current point release handling works quite well - 4 week fixed and plannable schedule, good quality patches in the release/ branches, so "make a release" is just version.m4 / Changes.md / ChangeLog editing, and pushing to buildbot host - 30 minutes, unless there is "writing up Changes.md" is hard because of too many patches. BB will test-build release, so there is an assurance the version.m4 commit didn't break anything.
+
+
2. we do not formally inform distros of dooming releases (informal heads up to debian and freebsd given) - do we want that?
+
+
3. Frank/Yuriy side: improvements?
+
1. remove debian/ubuntu package builds from build-openvpn -> build via build.opensuse.org (because SuSE supports "all the distros")
+
+
2. currently "t\_client" tests for Windows are not done on gerrit pushes, but on "push to openvpn-build" repo -> this could be improved --> "Lev has super-super comprehensive windows test framework now!" -> please integrate ;-)
+
+
5. Lev: dco-win (and dco?) CI test rig [https://lstipakov.github.io/dco-rig/](https://lstipakov.github.io/dco-rig/)
+
* very impressive coverage, 90.000 packets between clients, 20.000 sessions per run, iperf, misbehaving userspace, ...
+
+
* 4 pairs "stay connected all the time, run iperf", 16 "swarm" clients, 800 "flood" peers (gremlins)
+
+
* 7 EC2 instances, "a few EUR" per test <-> maybe not run this for every gerrit push?
+
+
* run this as nightly tests?
+
+
6. Merge handling
+
1. right now, Gert handles all the "merge final patches and push to sf/github/gitlab/gerrit/buildbot"
+
* with the review support from Razvan & the financial support from OpenVPN Inc, this works out reasonably well, and we've reduced the gerrit backlog quite a bit over the last 2 months
+
+
2. it would be useful to have at least one backup person in case of unavailability
+
* sf.net - who has access? David, Samuli, James?
+
* github, gitlab - who has access?
+
* tooling (git ack-am) to be shared Gert -> dev-tools/
+
* commit/tag signing is currently only done for release commits, using gert@ personal key
+
+
7. Heiko: Anthropic Mythos Access for OpenVPN?
+
* Option 1: "Claude for OSS" - maximum plan for free for 6 months, then pay for it
+
* Option 2: "Project Glasswing" - sounds like "security researchers" and "red teams" and such - we could apply?
+
* Option 3: "OSS Scanner" - dedicated repository on GitHub where you can file PRs that explain attack vector, etc., and how the scanner should behave, and results are mailed "to a mailing list" -> looks useful. Heiko plans to check with them how "different OS" builds are covered (Linux, Windows, ...) --> go for this one! (Help with Docker -> Frank)
+
* there is a paid version of "OSS Scanner" which might be used for "Corp stuff" eventually
+
8. Max: Signal group - "how trusted is it?"
+
* create a new group with "core developers" (at least: Frank, Gert, Arne, David, Antonio, Max, Steffan, Lev, Heiko + X) - "those in the room right now + David + Johan" sounds like a plan ;-)
+
* group clearly marked as "confidential for active core developers"
+
* existing group is re-chartered to be more loose "people involved in OpenVPN"
+
* memes and volcanoes to be posted to the "community group"
+
9. Ralf: UDP source port entropy
+
* inbound high-bandwidth crypto stream between "just two" entities can not be properly fanned-out to multiple CPUs because "same source+destination port" gets hashed to 1 CPU, 1 Queue
+
* idea: modulate UDP source port (bind not needed from within kernel, just set the source port)
+
* calculate inner hash, map to outer UDP source port
+
* get spread inner flows to multiple receive queues on the other side
+
* this is what VXLAN/GENEVE do "in data centers"
+
* can't use this for all scenarios ("if you are behind a stateful engine, state will explode")
+
* might cause issues with ECMP routing / LACP balancing
+
* will cause issues for packet-id / replay window checks, differential delay between flows, proportional to packet-per-second
+
* is incompatible with floating (= must not float on source port "change")
+
* "ignoring all this for first experiment" -> "it works, and gives a huuuge performance boost"
+
* on the receiving side -> replay-window shared between CPUs -> read-modify-write -> cache contention
+
+
* idea: every "lane" has its own receive window = no cache contention
* different crypto space for "sub-channels" (child SA), negotiated, derived from main
+
* assign child SA "to hardware resource", bounded to source port, nicer bidirectionality and NAT behaviour (= symmetric flow)
+
* inner flows mapped bidirectional to same "child SA" = helps with cache locality etc
+
* localized cryptographic state
+
* Question to the room...?
+
* "what makes sense? what do we want to adopt?"
+
* if "child SA" -> we need to do control-channel signalling
+
* Arne: #1 is very hacky, #2 is problematic with packet ID space limits (48 bit, but only 29 can be used due to AEAD limits) - "same key, IV space partitioned" - very small per-lane IV space (it would work with ChaCha or AEGIS)
+
* Steffan: "there is no good option with AEAD except do multiple keys"
+
* (discussion about technical details, bit length, data format, ...)
+
* rough result how an implementation could look like:
+
* server has multiple active sockets, set up by the admin, firewall ports openend ("it is known beforehand that these ports work")
+
* client connects
+
* server signals "I can do multi-channel, I would be willing to accept extra connections on <ip:port1>, <ip:port2>, <ip:port3>"
+
* client sends a CONTROL\_AUX packet to additional socket (= new "userland control-data channel" stuff, authenticated by peer-id + crypto")
+
* server acknowledges this, assigns a new peer-id for the subchannel (?)
+
* client sends a 3-way "let's do this!" CONTROL\_AUX PACKET
+
* data channel key is derived from original TLS session ("do not re-use the same identifier!")
+
* both ends instantiate a kernel peer (master peer-id, sub-channel peer-id) <<-- needs new kernel messages
+
* open question: what peer-id to use in which packets?
+
* identity of "what"?
+
* floating of subchannels?
+
* asymmetric peer-id?
+
* possibly de-couple "client id" (identifier between userspace and DCO) and "peer-id" (what is in the packet)
+
* "client id" can have "1..N" peer-id associated to it
+
* also rx-peer-id/tx-peer-id
+
10. Steffan: control channel test suite "it has been on the list since 2022! go merge it!"
+
--> new patchset on Gerrit, go review!
+
+
11. Arne: testing management/testing in general
+
* App-Custom-Control: client and server can exchange "custom" messages over openvpn transport, using management-interface on both ends
+
* two demo scripts for this available in gerrit
+
* needs management interface patch to actively run scripts "connected to mgmt-if"
+
* python scripts with python module (omi.py) to excercise management interface
+
* Question to the room: what do we want and what do we need?
+
* Frank: yes! test! all of it!
+
* Gert: extend t\_client to use management interface to drive client side (connect, disconnect, reconnect, test signal handling, counters, 2FA, --management-query-user-pass, --management-external-key...)
+
* run openvpn --management-script $driver
+
* Gert: extend t\_server tests to test management functionality (permit/reject clients, do delayed auth, IP assignment, PUSH\_UPDATE, ...)
+
+
* Steffan: this could nicely integrate with the TLS test suite Steffan is currently building (for "make check")
+
+
* TODO: review and merge patches in gerrit, then enhance t\_client, t\_server, .. tests
+
+
* ACC examples is master, but the "python framework handling things" should be in 2.7
+
* Arne: grab one of the AS python developers to help review
* everbody agrees on the concepts and the naming (PMH!)
+
* Arne and Steffan will write it down next week
+
+
13. Gert: agree on server-probe architecture ("which bit of the code gets to do what"), before going into individual patch review
+
* Lev: "this is mostly client side and I need to rewrite everything now"
+
* please update the highlevel document :-) and we look very closely at this next week
+
14. Heiko: can we have automated testing for the windows services?
+
* Frank: "we have some windows infrastructure" (AWS), we also have t\_client "alike" windows tests
+
* not run on every commit to openvpn main repo, just on push to openvpn-build repo
+
* Lev: "will fix my test rig to use latest-master .msi"
+
* how to test from gerrit?
+
* \*what\* to test from gerrit?
+
* for windows: split-dns, block-outside-dns testing looks interesting
+
* reference server ("phillip") has UDP, TCP, v4, v6 server instances that can push DNS if requested, etc. ("setenv IV\_WANT\_DNS=dns|dhcp" on the client side)
+
* Heiko: this looks good, but it's not testing the automatic service yet --> add work on this
+
* gui (-cli) can be used to monitor / restart / stop instances (if automatic configs have --management in them) -> Selva understands all the details
+
15. Lev: streamline dco-win releases (we now have EV/Authenticode signing automated, need to move builds from Lev machine to some AWS instance?)
+
* signing is done on Lev's laptop plus some machine in Community VPN today, and it's complicated with copying files and signed files back and forth 6 times
+
+
* improved scripting already - "one click!", but still built & signed on Lev's laptop
+
* it would need "Windows VM with right version of enterprise driver kit + community VPN access for signing"
+
* \-> Ball is with Frank and Yuriy to use the "windows installer building + signing" AMI for dco-win too, "we just need to do this"
+
16. Antonio: libdco, synchronize across linux/windows/freebsd?
+
+
17. next meeting? location and time?
+
* Oulu (July/August)
+
* Tallinn?
+
* Berlin?
+
* Istanbul?
+
* Zagreb? --> east-west-trajectory being followed
+
* Belgrade?
+
18. multipeer support?
+
* will we have something in 2.8? (no)
+
* Arne has proof of concept code, but it's "very rough"
