Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on libera.chat
Date: Wed 16th February 2022
Time: 10:30 CET (9:30 UTC)

Planned meeting topics for this meeting were here:

<https://community.openvpn.net/openvpn/wiki/Topics-2022-02-16>

Your local meeting time is easy to check from services such as

<http://www.timeanddate.com/worldclock>

SUMMARY

cron2, dazo, lev, mattock, MaxF and plaisthos participated in this meeting.

---

Talked about mbedTLS license incompatibility. MaxF asked about an "OpenVPN exception" on the mbedtls mailing list and they were not interested in granting one as they'd need to ask every contributor about it.

Decided to drop mbedTLS support from OpenVPN in 2.7. Meanwhile MaxF / Fox IT will keep the GPL-compatible version up-to-date with security fixes until then. We will point OpenVPN users to that repository and warn people about the license incompatibility.

---

Talked about the next 2.5 release. The only missing this is the plugin fix, which is next on cron2's list.

---

Talked about 2.6. The big frame/buffer changes are in. Next in line are DCO and DNS. DNS patchset should be ready for final review.

---

Talked about the OpenSSL 3 PR in openvpn-build:

<https://github.com/OpenVPN/openvpn-build/pull/231>

Agreed that having a separate branch for release/2.5 builds would be maintainable. Therefore the PR can be merged to master while retaining 1.1.1 builds in 2.5 releases.

---

Talked about custom triplets in the MSVC build. Lev will check if there is another way to do static linking. If not, he'll just use lz4.dll and get rid of them to simplify the buildsystem.

---

Noted that Trac can't send notifications because SMTP authorization fails. Mattock will create an internal ticket about it.

--

Full chatlog attached
(11.26.02) mattock: hello
(11.26.26) lev__: guten tag
(11.30.13) dazo: hey!
(11.32.04) mattock: anyone else?
(11.33.58) MaxF [~m...@cust-95-128-91-242.breedbanddelft.nl] è entrato nella 
stanza.
(11.34.09) MaxF: hello!
(11.34.12) mattock: hi!
(11.37.40) plaisthos: hi
(11.37.58) plaisthos: MaxF: btw. I was never contacted by however was looking 
into the license
(11.38.44) cron2: ups
(11.38.47) cron2: I am here
(11.39.14) cron2: alarm clock set to 10:25, decided to "just finish that 
commit"... *g*
(11.39.48) MaxF: plaisthos I don't think they will then. We're using the last 
version of mbedtls that is GPL for OpenVPN-NL 2.5.x
(11.40.20) MaxF: so we'll have to backport any security fixes ourselves
(11.40.47) MaxF: and from 2.6 onward I guess we'll use OpenSSL
(11.44.40) dazo: so ... sync-up?
(11.45.17) novaflash [~novafl...@185-227-75-241.dsl.cambrium.nl] è entrato 
nella stanza.
(11.46.07) cron2: so this sort of answered 2. "license issue?" already, no?  
We'll keep supporting GPL mbedTLS, and not Apache2 mbedTLS?
(11.47.08) cron2: have "you" (MaxF, plaisthos) mentioned this to mbedTLS folks?
(11.49.02) MaxF: I have asked on the mbedtls mailing list if it would be 
possible to make an exception for OpenVPN
(11.49.21) cron2: that would also work... so, any response?
(11.49.25) MaxF: they say they'd have to ask everyone who ever contributed 
code, so that's not possible
(11.49.52) cron2: but they already asked everybody for the GPL->Apache change...
(11.50.21) mattock: well, I can see the point about asking everyone for every 
single project that wants an exception
(11.50.24) cron2: but the signal is clear "they do not want OpenVPN to use 
mbedTLS anymore, then"
(11.50.25) dazo: maybe they forgot to do that when changing the license 
.........
(11.51.09) plaisthos: might be also that they still had full rights when going 
to apache 2 and giving it to the contribution from the arm site
(11.51.21) plaisthos: but the foundation does not have that rights anymore
(11.51.22) cron2: effectively this means we'll have to rip out mbedTLS support 
at some point, maybe for 2.7 - having all this code in there for a backend that 
we can no longer use
(11.51.38) MaxF: cron2 They've been offering GPLv2 **or** Apache, I don't think 
they needed to ask anyone to drop GPL.
(11.53.24) dazo: right
(11.55.01) mattock: anyhow, we keep supporting GPL mbedTLS and drop it in 2.7?
(11.55.49) cron2: annoyance, but this is my reading of the situation
(11.56.46) mattock: should we fork mbedTLS on GitHub then?
(11.57.02) mattock: make it official
(11.57.12) mattock: maybe some other project is in the same situation
(11.58.40) MaxF: we could also wait and see if we need to make any changes. 
Maybe we're lucky and we don't need to do anything until 2.7
(11.58.53) plaisthos: mattock: no, nobody of us wants to maintain mbed TLS
(11.59.32) dazo: I'm not sure we should fork mbedTLS ... that means we need to 
keep up with security updates and follow-up with that maintenance.  I'm not 
sure I see the value of that with mbed TLS.
(11.59.44) mattock: I'm not speaking of a real fork
(11.59.59) novaflash: are we going into matrix territory now?
(11.59.59) mattock: just a place where we (e.g. MaxF) puts the backported 
security fixes
(12.00.11) mattock: which we would dump at the earlier possible moment
(12.00.21) mattock: that said, we don't provide mbedtls builds of openvpn, do 
we?
(12.00.57) cron2: we do not provide mbedtls builds, and we should not 
fork/maintain mbedtls 2.x
(12.01.04) plaisthos: mattock: I think that was more MaxF talking about what 
FoxIt will do
(12.01.10) cron2: this
(12.01.11) plaisthos: not what the project should do
(12.01.12) dazo: ahh, I see ... In that case, I'd say MaxF can do what he finds 
most suitable, and we can surely host the git tree under our umbrella if he 
wants
(12.01.17) mattock: yep
(12.01.32) cron2: I would not object to that
(12.01.39) dazo: +1
(12.01.47) mattock: at most we should point people to a mbedTLS git repo that 
is up-to-date with security patches + license compatible
(12.01.57) mattock: so that they don't use obsolete software
(12.02.07) mattock: people = openvpn users who need mbedtls
(12.02.15) dazo: agreed
(12.02.32) mattock: MaxF invents a place and we take care of the rest :)
(12.02.37) MaxF: also, should we warn people that they don't accidentally ship 
something that violates licenses?
(12.03.00) MaxF: like, in the documentation about building with mbedtls
(12.03.16) mattock: I think that's a good idea
(12.03.19) dazo: +1
(12.03.44) MaxF: ok, will do!
(12.03.48) mattock: great!
(12.03.53) mattock: next topic?
(12.04.11) cron2: sync :-)
(12.04.54) cron2: not much really on 2.5 - "we'll do a release when the plugin 
fix is in" (and that one is "next on my list")
(12.05.46) cron2: on 2.6: Frame/Buffer is in \o/ - I have two open things left 
for plaisthos to fix (documentation on the mssfix default change and 'something 
I forgot') - but the big set is in and well-tested now
(12.06.42) cron2: so, plugin fix next
(12.06.45) cron2: then dco + dns
(12.07.33) cron2: ah, we have a CVE as well
(12.08.01) cron2: (I did not properly follow that discussion, so "do we already 
have a CVE number?" was on my to-do list)
(12.08.50) dazo: Yes, we have CVE number for that issue
(12.10.01) dazo: It should all be on the security list .... I believe we have 
everything ready, it's just to merge patches and start the release machinery 
for 2.4 and 2.5
(12.10.17) dazo: That will close the 2.4 branch and move it to oldstable
(12.11.10) cron2: yes.  I'll look into it this week
(12.11.37) dazo: if I'm not responding on IRC, feel free to ping me on Signal, 
cron2
(12.11.45) cron2: what state is the DNS patchset in?  I think I've seen a PR 
with "looks good" but no patches on the list
(12.11.48) cron2: dazo: yep
(12.12.15) cron2: (have to add your contacts to my phone contacts so Signal 
will acknowledge you exist... :-) )
(12.12.23) dazo: I thought the DNS patches was somewhat ready for final review 
...
(12.12.27) plaisthos: cron2: there is also the dns serv patch 
(12.12.32) cron2: dns serv?
(12.12.38) plaisthos: srv record
(12.12.42) cron2: SRV, yes
(12.13.09) cron2: plus a bit of this and that (--iroute-ipv6, ifconfig cleanup)
(12.13.11) cron2: ah, btw
(12.13.35) cron2: MaxF: could you give "master" a new test with --disable-lzo 
--disable-lz4?  I think it should be all fine now (again)
(12.14.01) MaxF: I'll give it a try
(12.15.11) cron2: anything else to sync?
(12.16.32) lev__: @mattock there is PR to openvpn-build about openssl3
(12.16.41) mattock: oh that one yes
(12.16.51) dazo: If there are anything you want me to review, I believe I 
should have some time available for that this week as well
(12.16.55) mattock: I think I wanted to test that, then got distracted etc
(12.17.22) mattock: let me check
(12.17.34) lev__: openssl3 support has been merged into openvpn (vcpkg port 
etc) so there is corresponding part in openvpn-build
(12.17.37) cron2: dazo: on the DNS patches - yes, that.  PR reviewed and OKed, 
but no patches on the list, yet
(12.17.57) mattock: https://github.com/OpenVPN/openvpn-build/pull/231
(12.18.29) cron2: last thing in there is a question to mattock :)
(12.18.30) mattock: lev: regarding the question in the PR
(12.18.31) mattock: yes
(12.18.40) mattock: I think the MSI stuff is fairly stable now
(12.18.48) dazo: cron2: I'll follow up with d12fk .... he's doing lots of stuff 
at night hours, so I'll catch up with him in the afternoon
(12.18.50) mattock: so a branch  could probably work
(12.19.08) novaflash ha abbandonato la stanza (quit: Quit: Client closed).
(12.19.31) mattock: let's do that unless somebody objects
(12.20.08) cron2: sounds good to me
(12.20.22) lev__: one small thing about msvc build
(12.21.17) lev__: we use custom vcpkg triplets (like x64-windows-ovpn) only 
because we link lz4 statically
(12.21.50) lev__: and we do that only because cron2 decided to link lz4 
statically in generic buildsystem
(12.22.13) lev__: getting rid of custom triplets will remove some code and 
simplify build process
(12.23.05) lev__: if we could survive with lz4.dll I suggest to remove custom 
triplets, they serve no purpose except "if this lib is lz4, link statically"
(12.23.18) mattock: sounds reasonable to me
(12.23.21) mattock: less complexity is good
(12.24.02) cron2: I think that was a quick shot only to make MSVC builds 
happen... otherwise, well, a single-user-dll is not particularily useful...
(12.24.53) cron2: but if it reduces maintenance for the build system, why not
(12.26.07) lev__: by default vcpkg uses dynamic linkage, I couldn't find 
another way except custom port to link certain library statically
(12.28.30) mattock: ok so we agree that lev's proposal is ok?
(12.29.19) lev__: I'll check again if there are other ways to link statically 
without custom triplets and if not, we go with dll and get rid of custom 
triplets
(12.29.32) mattock: +1
(12.29.57) cron2: +1
(12.31.54) mattock: anything else, 1 minute overtime
(12.32.06) cron2: JFYI for the round and the minutes
(12.32.16) cron2: TRAC currently cannot send e-mails due to SMTP issues
(12.32.19) mattock: yes
(12.32.34) cron2: mattock is pointing/poking the right people, or so
(12.32.36) mattock: I'll create an internal ticket about it
(12.32.37) mattock: now
(12.32.48) cron2: thanks
(12.32.49) mattock: hmm
(12.32.57) mattock: I wonder if I still have SSH access to the thing :)
(12.33.45) mattock: I do, good
(12.33.50) cron2: good :-)
(12.34.14) cron2: so, 3 minutes overtime - we'll postpone IPv6 and buildbots to 
next week, then... ("nothing to report" I assume)
(12.36.04) mattock: yep
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to