Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 17th August 2022
Time: 10:30 CEST (9:30 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2022-08-17>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
berniv6, cron2, d12fk, dazo, djpig, lev, mattock, MaxF, ordex and
plaisthos participated in this meeting.
---
Talked about hackathon. Noted that many people have not answered the
Doodle poll yet. They should.
---
Talked about DCO and NetworkManager. After a long discussion the patch
to be created boils down to "if we have no CAP_SETPCAP and --user,
disable dco".
In other words the short-term fix is to disable DCO when CAP_SETPCAP is
not available, and the long-term fix needs to be talked about with the
NetworkManager team.
---
Talked about what OpenVPN version Debian should bundle. Cron2 and
berniv6 agree that the plan is that we have 2.6.x ready at Debian
release freeze so they can just ship it.
Unfortunately downstream distros like Ubuntu and Kali Linux used
experimental OpenVPN code from Debian experimental/sid as a basis for
their own OpenVPN packages. So our strategy to address the bugs in
Debian testing "ASAP" and then send a heads up to those distros so that
they know to update their OpenVPN codebases.
Noted that OpenVPN 2.5 -> 2.6 upgrade combined with the OpenSSL 1.1.1 ->
3.0.0 upgrade will break things. Debian users should be shown a
notification when they're about to do such an upgrade.
---
Talked about OpenVPN 2.6 status:
<https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26>
Cron2's plan is to get FreeBSD DCO tested on the server side and then
merge the 2/2 patch of that. Then stare at the Windows patches, get a
working build environment then get that stuff merged. It seems possible
to have all code in by mid/end October and to make the release on
December 1st. For Debian project end of January is the "still get things
into packages easily" -deadline.
---
Noted that there is a tap-windows6 fix, so a new MSM needs to be created
and signed. We also want testable OpenVPN MSI installers that bundle the
new MSM.
--
Full chatlog attached
(11:29:29) mattock3: Hi!
(11:29:37) cron2__: ho
(11:29:41) MaxF: hi!
(11:29:54) dazo: o/
(11:29:58) cron2__ ha scelto come argomento:
https://community.openvpn.net/openvpn/wiki/Topics-2022-08-17
(11:29:58) lev__: hello
(11:30:19) ordex: goedentag
(11:30:59) berni [~berni@2a01:170:1181:0:6600:6aff:fe6a:9cf4] è entrato nella
stanza.
(11:31:14) berni: hi
(11:31:27) ordex: hi berni
(11:31:43) cron2__: hi, cool that you could make it
(11:31:57) cron2__: where did you leave your signature "v6"? :)
(11:32:05) berni: I'm still in a meeting, might delay my answers a bit
(11:32:08) berni è ora conosciuto come berniv6
(11:32:30) dazo: lost in a v6-in-v4-nat translation? :-P
(11:32:35) cron2__: this is the spirit :)
(11:32:37) ordex: :D
(11:32:58) cron2__: so, d12fk and djpig coming? or on vacation?
(11:33:09) ordex: almost here
(11:33:22) dazo: fighting about rfc structures in a meeting room ;-)
(11:33:37) plaisthos [~arne@openvpn/developer/plaisthos] è entrato nella stanza.
(11:33:37) modalità (+o plaisthos) da ChanServ
(11:33:51) plaisthos: oh my client did not join here
(11:34:28) lev__: we're all in the same room
(11:35:12) cron2__: hackathon - missing feedback from (at least) dazo and d12fk
(11:35:19) cron2__: doodle, that is
(11:35:30) ordex: and me too
(11:35:31) ordex: darn
(11:35:52) ordex: anybody has the link at hand?
(11:35:55) dazo: yikes!
(11:36:12) cron2__: it might be this one
https://doodle.com/meeting/participate/id/dRgEwERe
(11:36:14) vpnHelper: Title: Doodle (at doodle.com)
(11:36:37) L'account è disconnesso e non sei più in questa chat. Sarai
reinserito in questa chat alla riconnessione dell'account.
(12:17:12) L'argomento di #openvpn-meeting è:
https://community.openvpn.net/openvpn/wiki/Topics-2022-08-17
(12:17:12) L'argomento per #openvpn-meeting è stato impostato da
cron2__!gert@openvpn/developer/cron2 a 11:29:58 su 17/08/2022
(12:17:12) berniv6: on the OpenVPN side with a big fat warning, I don't think
that having nm-openvpn add --disable-dco is easier
(12:17:12) cron2__: the problem is that the code flow right now makes this
extremely messy
(12:17:12) cron2__: openvpn connects, pulls options from the server, sets up
tun or dco interface, *then* drops privileges
(12:17:12) cron2__: notices "damn, can't keep capabilities"
(12:17:12) cron2__: but that's way too late to disable DCO
(12:17:12) ordex: is there anyway to do a "pre-check" ?
(12:17:12) ordex: like a set_cap dry run
(12:17:12) berniv6: the problem is that NM removes the CAP_NET_ADMIN priviledge
before even starting the daemon, right? Can we somehow test this?
(12:17:12) berniv6: a stop, it has to have the priviledge at this point,
otherwise the initial connection won't work either
(12:17:12) cron2__: if (user && dco && try_setcap_fails() ) { disable_dco; }
(12:17:12) ordex: I think there is a way to check for the available caps
(12:17:12) ordex: cron2__: yeah
(12:17:12) cron2__: dazo: you understand what NM does
(12:17:12) berniv6: so does anyone know what the process does have
CAP_NET_ADMIN in the beginning, but cannot keep it will dropping priviledges?
(12:17:12) dazo: Yeah, I have an idea why that happens
(12:17:12) cron2__: this is what I do not understand - it must be started with
"root privs", otherwise initial interface setup won't be possible. Then,
--user kicks in, and we try to keep CAP_NET_ADMIN
(12:17:12) dazo: nm-openvpn is kicked off through some NM privilege escalation
paths .... it's complicated
(12:17:12) cron2__: so, if we have root, why is it possible that we can not
keep CAP_NET_ADMIN?
(12:17:12) dazo: the unprivileged user asks the NM daemon to start the VPN
session, which runs with more privileges ... and that kicks off the openvpn
process again
(12:17:12) ordex: dazo: but the new openvpn proces should have enough privs to
configure the network, no?
(12:17:12) berniv6: I think the error message gives a hint
(12:17:12) ordex: *process
(12:17:12) berniv6: Aug 15 09:24:46 myhostname nm-openvpn[11804]:
capng_change_id() failed applying capabilities: Operation not permitted
(errno=1)
(12:17:12) berniv6: Aug 15 09:24:46 myhostname nm-openvpn[11804]: NOTE:
previous error likely due to missing capability CAP_SETPCAP.
(12:17:12) ordex: ah indeed, maybe the process is missing CAP_SETPCAP
(12:17:12) dazo: That NM privileged service probably lacks CAP_SETPCAP
(12:17:12) ordex: but, shouldn't then the NM process already own CAP_NET_ADMIN ?
(12:17:12) cron2__: so you can have "effective uid = root" but not CAP_SETPCAP?
(12:17:12) berniv6: https://man7.org/linux/man-pages/man7/capabilities.7.html
(12:17:12) vpnHelper: Title: capabilities(7) - Linux manual page (at man7.org)
(12:17:12) dazo: cron2__: yes
(12:17:12) cron2__: ok, this explains why the open() and later setuid(nobody)
works, but not the SETPCAP
(12:17:12) ***dazo see we need the nm-openvpn3 plugin :-P (that does
privilege separation completely differently and avoids the NM privilege traps)
(12:17:12) ordex: but if the process was already manipulated, is it possible
that it already has CAP_NET_ADMIN? so actually we don't need to do the set_cap?
(12:17:12) cron2__: dazo: yeah, this might be a reasonable end goal
(12:17:12) dazo: I need to have a look at the SETPCAP patch again ... perhaps
we could check if we have CAP_NET_ADMIN, and the skip the setcap() call
(12:17:12) ordex: dazo +1
(12:17:12) ordex: we should be able to check the set
(12:17:12) cron2__: why would setcap() fail if we already *have* that
capability?
(12:17:12) cron2__: but anyway
(12:17:12) cron2__: we could do a pre-check
(12:17:12) ordex: cron2__: because we have no cap_set_cap so the call fails
before doing anything
(12:17:12) ordex: (my understanding)
(12:17:12) djpig: isn't the point that we definitely have it, but we want to
drop the other permissions
(12:17:12) cron2__: "if we have neither CAP_SETPCAP nor CAP_NET_ADMIN, and
--user is requested, then disable(dco)"
(12:17:12) dazo: the setcap() call is blocked _before_ the capabilities
requested are being processed
(12:17:12) cron2__: djpig: not sure if we have it. We are root at this point,
so maybe netlink is happy with "if (root || CAP_NET_ADMIN)"
(12:17:12) djpig: I don't think anything cares about whether you're root. root
only defines your initial capability set
(12:17:12) ordex: most likely, yeah
(12:17:12) dazo: In many code kernel paths that's right
(12:17:12) cron2__: dazo: which of the two? ;-)
(12:17:12) djpig: so if we do not have SETPCAP and --user is requested then
disable dco because we can't retain CAP_NET_ADMIN, right?
(12:17:12) dazo: The capabilities checks .... there are some code paths
checking uid==0, but more and more migrates over to capabilities checks
(12:17:12) cron2__: djpig: "if we have neither SETPCAP nor CAP_NET_ADMIN", no?
Because if we have CAP_NET_ADMIN, all is good. Or would that be lost on
setuid()?
(12:17:12) cron2__: dazo: makes sense
(12:17:12) djpig: cron2__: no, we loose it when switching the uid, right?
(12:17:12) MaxF: if you replace uid == 0 with capability checks, will this
still work on *BSDs?
(12:17:12) cron2__: MaxF: BSDs do nothing so advanced, so this is all #ifdef
TARGET_LINUX
(12:17:12) djpig: the whole thing is about KEEPING CAP_NET_ADMIN even after
switching to the different user
(12:17:12) djpig: not about aquiring it
(12:17:12) ordex: cron2__: yeah, what djpig says: if we can't do setcap, then
we will lose NET_ADMIN upon --user switch
(12:17:12) cron2__: okay
(12:17:12) ordex: so if we have --user we must be able to do setcap
(12:17:12) cron2__: so setuid() will clear all capabilities unless we've
ordered "keep that one!"
(12:17:12) cron2__: ordex: okay. So the patch simplifies to "if we have no
CAP_SETPCAP and --user, disable dco"
(12:17:12) ordex: cron2__: yap, that would be my conclusion
(12:17:12) cron2__: and print a big fat warning "because NM is so nasty, you
now get a slow VPN!"
(12:17:12) berniv6: sounds good ... and one could then go to the NM guys and
request them to give CAP_SETPCAP to the openvpn process
(12:17:12) cron2__: yep. So you get a working openvpn-devel package for the
time being, and in the long run, we hopefully get NM+DCO
(12:17:12) berniv6: as far as I understand the process can't get _additional_
capabilities with that, right? It will just be able to retain the (already
given) CAP_NET_ADMIN capability
(12:17:12) ordex: cron2__: question: but if are in this constrained situation,
does it mean that NM has already changed user and manipulated the capabilities?
so does it make sense to have --user when using NM at all?
(12:17:12) cron2__: ordex: nothing makes sense when NM is involved :-) - but
from the error message in the thread, we try to do the setuid()/setcap() dance
(12:17:12) dazo: IIRC, you need CAP_SYS_ADMIN or CAP_SETPCAP to be able to use
setcap() related calls
(12:17:12) cron2__: which we only do if passed --user
(12:17:12) ordex: ok
(12:17:12) dazo: CAP_SETUID is what's needed for setuid()
(12:17:12) cron2__: if NM were to start us with CAP_NET_ADMIN *and*
user=nobody, but without actually passing --user nobody, things would not run
into *this* error message. It might actually just work...
(12:17:12) dazo: $ pscap | grep -i networkm
(12:17:12) dazo: 1 3640 root NetworkManager dac_override,
kill, setgid, setuid, net_bind_service, net_admin, net_raw, sys_module,
sys_chroot, audit_write
(12:17:12) ordex: I guess we have enough info to make some "tests"
(12:17:12) dazo: that's the privleges networkmanager has on RHEL-8
(12:17:12) dazo: no set_pcap, which we need for our setcap() calls
(12:17:12) cron2__: so. I think we have a path forward on this? Short-term
fix, and long-term discussion with NM?
(12:17:12) dazo: Yeah, short-term is to disable DCO when CAP_SETPCAP is not
available .... long-term discuss with NM how to solve this
(12:17:12) ordex: seems so, I guess we still need to do some tests, because we
are making assumptions on what NM does
(12:17:12) dazo: NM doesn't give us enough power to start with
(12:17:12) cron2__: dazo: do you have working contacts in the NM camp?
(12:17:12) dazo: I do
(12:17:12) cron2__: cool.
(12:17:12) dazo: there's also #nm ;-)
(12:17:12) cron2__: yeah, but showing up there un-introduced and complaining
that their stuff is buggy is not the best way to make contacts :)
(12:17:12) cron2__: anyway. I need to leave at 11:30 (or at least listen to a
videocall)
(12:17:12) dazo: I'll ask there ... Just need to figure out the nm-openpvpn
plugin maintainer nick ... I have it somewhere
(12:17:12) cron2__: since berniv6 is here, shall we address the other relevant
topics, namely "what should debian and ubuntu bundle"?
(12:17:12) ordex: yes
(12:17:12) cron2__: this is more a plaisthos sore point...
(12:17:12) cron2__: dazo: thanks
(12:17:12) berniv6: I'm not aware of that discussion, so I need some intro
(12:17:12) cron2__: if I remember right, the starting point was "ubuntu
something ships openssl 3.0 today, with openvpn 2.5"
(12:17:12) cron2__: which breaks, of course, so we asked them to pull up
patches for better openssl 3 support
(12:17:12) berniv6: that's quite possible, but I don't do Ubuntu :-)
(12:17:20) cron2__: yeah
(12:17:24) plaisthos: berniv6: the thing that we now have a master snapshot
with experimential dco patches on top in ubuntu 22.10 since they picked up your
version from experimential/sid
(12:17:42) cron2__: in that bug report, they brought up 22.10, which pulled in
debian-testing with the experimental version
(12:18:20) berniv6: yes, that's unfortunate
(12:18:21) cron2__: *I* am fine with "bleeding-edge openvpn in debian-testing"
because that way we can ensure proper working stuff at release freeze
(12:18:32) cron2__: Ubuntu shipping that in 22.10 is less than ideal
(12:18:44) cron2__: not sure if plaisthos has reservations with debian-testing
(12:18:54) cron2__: so, you two, speak now :-)
(12:19:10) plaisthos: I don't want a master snapshot+unstable patches on top to
show up in a released Linux distro
(12:19:14) plaisthos: I don't about testing
(12:19:23) plaisthos: I don't care about testing
(12:19:34) berniv6: I have another bugreport with Kali in the same direction,
that has quite royally pissed me off:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014376
(12:19:37) vpnHelper: Title: #1014376 - openvpn: Using unreleased version with
backwards incompatible changes is not a good idea - Debian Bug report logs (at
bugs.debian.org)
(12:19:38) berniv6: this time Kali Linux
(12:19:52) cron2__: my (and berniv6) plans for debian is "we have 2.6.x ready
at debian release freeze and can ship it"
(12:20:03) berniv6: problem is, if I push it into experimental, only the very
very dedicated testers for this package can actually enable it
(12:20:24) berniv6: as soon as I put it in unstable, it will eventually land in
testing. Plus testing has at least ten times the users that unstable has
(12:20:45) berniv6: some of the bugs already found only appeared because
someone in testing hit it
(12:20:55) ordex: yap
(12:21:15) ordex: that makes sense. but why are other distros pulling from
testing/unstable? :-(
(12:21:18) berniv6: there is not much I can do about downstream derivates
(Ubuntu, Kali) just pulling it out of some random testing snapshot
(12:21:43) ordex: I guess the only thing we can do is opening a bug repor with
the distros
(12:21:47) berniv6: that's unfortunately the way those two work
(12:21:53) ordex: plaisthos: did you already look into doing that for ubuntu?
(12:22:05) berniv6: usually for both of them it's not a large deal pulling a
newer version out of testing
(12:22:24) berniv6: even after the release if it turns out to be necessary
(12:23:07) berniv6: Ubuntu 22.10 would probably still sync automatically if
20220811 would go into testing (which is blocked with the setcap thing)
(12:23:11) cron2__: so the strategy is - we see that we address bugs in debian
testing "ASAP", and then send a heads up to ubuntu, kali?
(12:24:34) berniv6: and Kali .. well, they complained that OpenVPN 2.6 won't
work with some stone age commercial openVPN providers
(12:24:48) berniv6: which is unlikely to be changed with a final 2.6 release,
so ....
(12:25:16) cron2__: --tls-cert-profile stoneage
(12:25:33) berniv6: cron2__: yup, that would be my strategy. With the
unfortunate amount of breaking changes 2.5 -> 2.6 there is no way we can
upgrade to 2.6 shortly before the freeze
(12:25:42) cron2__: so yeah. 2.6 release notes will need a big fat warning.
But it's good that we hear about that already.
(12:26:12) berniv6:
https://sources.debian.org/src/openvpn/2.6.0~git20220811-1/debian/NEWS/
(12:26:14) vpnHelper: Title: File: NEWS | Debian Sources (at sources.debian.org)
(12:26:31) berniv6: that one should be displayed to every user upgrading to 2.6
from the CLI by default
(12:28:37) plaisthos: part of the breakage is 2.6 but other half is OpenSSL 3.0
(12:28:47) plaisthos: so even without the changes things would have broken
(12:29:22) plaisthos: as we would not have started because we would have failed
on BF-CBC
(12:29:57) cron2__: berniv6: maybe add a note about the OpenSSL issues,
requiring use of "--providers legacy default" if the other side insists on
using BF-CBC and "--tls-cert-profile insecure" if SHA1 or MD5 certificates are
in use?
(12:30:20) cron2__: especially the SHA1 issue will bite people big time...
(like, all my corp VPN setups...)
(12:31:14) berniv6: sure, we can amend this
(12:31:50) berniv6: if anyone has a wording for that, I can merge it with the
next upload
(12:31:54) cron2__: that should help a bit
(12:32:54) cron2__: mmmh, wording is not easy. I'll start drafting something.
(12:36:04) plaisthos: OpenVPN 2.6 drops outdated ciphers (non AEAD based ones)
and TLS version (< 1.2) by default. If you need to connect to a very old
OpenVPN server (< 2.4) you need to have to enable compat-version 2.3.
Idendently, OpenSSL 3.0 has restricted its supports of old ciphers and weak
certificates, so the options tls-cert-profile insecure and/or providers legacy
default might need be needed
(12:36:11) plaisthos: as starting point
(12:36:57) plaisthos: ...connect to very old OpenVPN server or need to support
very old clients (<2.4)
(12:38:22) cron2__: yeah, three or four different ways to amend things
(12:38:25) cron2__: --compat-version
(12:38:36) cron2__: --data-channel-ciphers BF-CBC:...
(12:38:41) cron2__: --providers legacy default
(12:38:45) berniv6: https://itsubuntu.com/ubuntu-22-10-kinetic-kudu/
(12:38:46) vpnHelper: Title: Ubuntu 22.10 ‘Kinetic Kudu’ Release Schedule |
Itsubuntu.com (at itsubuntu.com)
(12:38:48) cron2__: --tls-cert-profile insecure
(12:39:50) berniv6: according to that Ubuntu 22.10 Debian Import Freeze is on
August 25th ... I'm only here until tomorrow, if I get a somewhat tested patch
by tomorrow evening I can upload, then it should migrate to testing on 23rd,
and Ubuntu 22.10 should still get it without manual intervention
(12:41:11) cron2__: but this means 22.10 will have a master snapshot, which
will contain a number of interesting issues?
(12:41:26) cron2__: I'd really prefer if 22.10 would ship 2.5.7
(12:41:47) mattock: sounds more reasonable
(12:43:07) cron2__: (we can certainly see that we can get the cap/dco thing in
by tomorrow, but this is still not a good basis for 22.10)
(12:43:28) berniv6: cron2__: right now it does have the master snapshot. There
never was a 2.5.7 (or 2.5.6 + openssl3) in Debian
(12:43:46) berniv6: so if Ubuntu 22.10 should ship 2.5, they would have to do
this on their own
(12:44:01) berniv6: that needs a lot more work on the Ubuntu side
(12:44:34) cron2__: berniv6: their 22.04 openvpn seems to be a local build
(12:44:41) cron2__: like, 2.5.5 with patches or so
(12:45:41) berniv6: possible. Not based on Debian though, and since version
numbers have to increase they would need to rebuild that as 2.6.0~really2.5.5
version
(12:45:59) cron2__: ewwwwww
(12:46:21) ordex: lol
(12:46:25) plaisthos: 22.04 has the problem they use OpenSSL 3.0 already so
they have a bunch of problem that the debian upstream with openssl 1.1.1 just
doesn't have
(12:48:37) cron2__: so, my other call has already concluded :)
(12:49:35) dazo: I ship 2.5.7 in Fedora 36 with OpenSSL 3, iirc
(12:49:54) plaisthos: yes but those patches in 2.5.7 are all the backport I did
for ubuntu 22
(12:50:27) lev__: cron2__: did you have a change to look into follow-up dco-win
patches? I have tested those, stared at the code and acked a few
(12:51:56) cron2__: lev__: people were yelling at me from all directions, so,
not yet
(12:52:28) cron2__: this is the "sync on 2.6" bit - my plans are "get FreeBSD
DCO tested on the server side, merge the 2/2 patch of that", and "stare at the
win patches, get a working build environment, get that stuff merged"
(12:52:31) ordex: stop yelling at cron2__ !!!
(12:52:43) cron2__: and stop finding bugs in DCO...
(12:53:13) cron2__: that wiscii p2p reneg thing yesterday ate quite a bit of
time I could have watched Disney+^W^Wmerged patches instead
(12:54:37) cron2__: so
(12:54:47) cron2__: shall we spend a few thoughts on openvpn 2.6.0 release
timeline?
(12:55:01) cron2__: berniv6 wants 2.6.0 in debian "by end of the year"
(12:55:05) cron2__: wants/needs
(12:55:23) ordex: I think we also need 2.6.0 out by the end of the year
(12:55:28) dazo: agreed
(12:55:38) cron2__: I think we can have "all code in" by mid/end October
(holiday season)
(12:55:47) ordex: (holiday again?)
(12:55:49) plaisthos: cron2__: ordex and I will look into the p2p stuff
(12:55:54) dazo: https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26
(12:56:10) plaisthos: and we volunteered d12fk to review my outstanding patches
(12:56:15) cron2__: so "testing, alpha, beta" in November, release "Dec 1"?
(12:56:43) cron2__: berniv6: "end of the year" means "Dec 31" or something else?
(12:56:58) ordex: assuming we can fix all bugs by end of november
(12:57:07) cron2__: we'll have to :)
(13:00:18) dazo: +1
(13:01:02) cron2__: quite a bit of work falls out of this - 6.+7. on the
agenda, "get current packages out to the distros" (freebsd <- mine) and
"windows buildslave with actual tests"
(13:01:37) cron2__: FC testing when we have the NM issue fixed/workarounded
(13:02:08) ordex: ay
(13:02:12) ordex: meeting over I'd say?
(13:02:35) cron2__: well, there's 2.5 + windows bits, but mattock has
disappeared anyway
(13:02:42) cron2__: so, yeah, let's conclude and get to work
(13:02:45) cron2__: berniv6: thanks for coming
(13:02:46) plaisthos: so most people here go to lunch now
(13:04:21) mattock: I have not disappeared unfortunately
(13:04:28) mattock: just writing the summary of what you babble about :)
(13:04:50) mattock: but I agree that we should end this thing, 1 hour 34
minutes already
(13:05:20) berniv6: cron2__: preliminary bookwork freeze dates
https://lists.debian.org/debian-devel/2022/03/msg00251.html
(13:05:21) vpnHelper: Title: Bits from the Release Team: bookworm freeze dates
(preliminary) (at lists.debian.org)
(13:05:47) cron2__: ok
(13:05:58) berniv6: so with the beginning of February it will become hard to
get anything fixed, I'd prefer a release in 2022 so we can iron out bugs in
January
(13:06:18) cron2__: yep
(13:06:56) berniv6: but basically, whether the release has been tagged or it
hasn't been tagged is irrelevant for me, I can continue to upload git
snapshots. I just don't want bookworm to be released with a snapshot, and the
last date to get anything uploaded without asking for permission is end of
january
(13:07:16) berniv6: and I don't want bookworm to be the only distro carrying
2.6 :-)
(13:08:00) cron2__: dazo will push FC, gentoo will rolling-upgrade, and freebsd
will pick up 2.6 - so you won't be alone :-)
(13:09:36) cron2__: mattock: since you're still here... we pushed a fix from
lev to the tap6 repo, so that needs a new version number and signed release...
(13:09:45) cron2__: and then a windows testing installer with the new tap driver
(13:10:04) cron2__: (item 5. on the agenda)
(13:18:30) mattock: oh shit
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
