Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 15th December 2021
Time: 14:00 CET (12:00 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2021-12-17>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, d12fk, lev, mattock, MaxF, novaflash, ordex, plaisthos,
rob0 and syzzer participated in this meeting.
---
Talked about the mbedtls dropping dual licensing (GPLv2 + Apache License
2) in favor of Apache License 2. This will probably make OpenVPN, which
is GPLv2 only, incompatible with mbedtls. The question here depends on
whether mbedtls can be considered a system library. If yes, our use of
mbedtls would not trigger license incompatibility. Agreed that
contacting an open source license lawyer about it might be a good idea.
---
Agreed to change meeting time to 10.30-11.30 CET/CEST. This works for
everyone who attends the meetings regularly, except rob0 from the US,
who was fine with the change nevertheless.
---
Talked about Google Titan and Yubikey giveway. Agreed that community
developers should get the free ones and OpenVPN Inc. developers can get
ones from the company.
---
Talked about mssfix. Agreed to set default mssfix to 1492.
--
Full chatlog attached
(15.00.14) mattock: hello
(15.00.20) MaxF: hello!
(15.00.30) mattock: hi!
(15.02.12) lev__: hello
(15.02.38) d12fk: hihi
(15.02.44) mattock: hi all!
(15.03.01) mattock: cron2 said he will join but may be distracted
(15.03.48) plaisthos: hey!
(15.03.55) plaisthos: MaxF: have you seen the license mail?
(15.04.09) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2021-12-15
(15.04.12) MaxF: yes, and I did some googling
(15.04.29) MaxF: GPLv2 and Apache don't seem to be compatible :/
(15.04.47) cron2: I'm here, but we're having a heated discussion $overthere
about VPN access to corp network...
(15.05.01) MaxF: http://www.gnu.org/licenses/license-list.html#apache2
(15.05.42) cron2: is dazo around? he seems to understand licensing best (from
the core team)
(15.05.46) cron2: can one of you wake him? :-)
(15.06.00) mattock: I tried already
(15.06.14) mattock: he woke up
(15.06.24) dazo: I'm here!
(15.08.22) dazo: So ... GPLv2 is incompatible with Apache License 2 ....
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses
(15.09.05) ordex: heya
(15.09.09) ordex: partly here too!
(15.10.42) plaisthos: MaxF: maybe Fox IT has still contacts with mbed TLS
people and ask if there is any chance for our GPL2 only project ot be able to
continue to use mbed TLS
(15.11.25) MaxF: I don't think we still have contacts, but I'll ask around
(15.11.36) dazo: In regards to the LZO license exception .... That is for
OpenSSL only. The question is if OpenSSL or LibreSSL can be considered a
system library; likewise for mbed TLS. But that is not something we can
decide, that is the distro needing to define that.
(15.12.31) ordex: basically who builds the package?
(15.13.49) dazo: kinda ... both the SSL/TLS library packager but also the whole
OS/distro project, I'd say
(15.14.26) MaxF: in OpenVPN-NL, we statically link with an mbedtls version that
we check out, so I don't think we can claim it's a system library
(15.14.30) dazo: "We consider the SSL/TLS library a critical and important
component of this OS. It cannot function without it"
(15.14.50) MaxF: or am I misunderstanding that term?
(15.14.54) dazo: MaxF: That is true, static linking breaks the system library
part
(15.15.17) cron2: windows building also breaks it, as we ship the SSL library
(OpenSSL, in that case)
(15.16.18) dazo: The OpenSSL 1.x and older license challenge is a bit
different, so there *we* need to grant a linking exception. While with the
Apache license that is the reverse, I believe
(15.17.00) plaisthos: with apache it is the same for OpenVPN + OpenSSL 3.0
(15.17.15) dazo: Yeah, that is something which will bite us too
(15.18.34) plaisthos: You must obey the GNU General Public License in all
respects for all of the code used other than OpenSSL.
(15.18.39) plaisthos: is what we have in our COPYING
(15.18.57) dazo: MaxF: in regards to static linking ... if the OS you build on
provides a static linkable version, linking against that would probably be fine
and considered part of the system library. But building your own mbed TLS and
linking statically will not be a system library.
(15.19.04) plaisthos: so if something in the GPL would not hold true for the
OpenSSL library then you still free to use
(15.19.40) MaxF: dazo Well, that's unfortunate
(15.20.34) mattock: perhaps this would be material for an open source license
specialist
(15.20.44) dazo: Yes, I think so
(15.21.16) mattock: we want to avoid screwing this thing up, especially if we
have to go through the relicensing process
(15.21.26) dazo: I see our OpenVPN 2 Copying even has a linking grant from
Oberhumer, when used against OpenSSL (no version/license restriction)
(15.22.29) plaisthos: I think the summary is that we are lucky that our
exception for OpenSSL was broad enough to cover also their license switch and
for mbed TLS we screwed :/
(15.24.31) plaisthos: we could try to reach all commiters if they are fine with
another
(15.24.34) plaisthos: license
(15.24.35) plaisthos: Despite our best efforts, the FSF has never considered
the Apache License to be compatible with GPL version 2, citing the patent
termination and indemnification provisions as restrictions not present in the
older GPL license. The Apache Software Foundation believes that you should
always try to obey the constraints expressed by the copyright holder when
redistributing their work.
(15.24.46) plaisthos: btw. this the reason gplv2 is incompatible with Apache 2.0
(15.25.17) dazo: unfortunately, yes. If we get a license grant from mbed,
things might end up different ... but we should consider getting in touch with
a GPL license lawyer
(15.25.54) mattock: dazo: you still have the contacts?
(15.26.04) mattock: Pamela if I recall correctly
(15.26.34) dazo: yeah, I would send this via Gary
(15.26.40) mattock: +1
(15.26.44) mattock: shall we move on?
(15.27.20) mattock: lots of topics
(15.27.41) cron2: can we return to "meeting time"? This is about: Wednesday
14-1500 works increasingly poor for me - it conflicts with family, US
videoconfs, ...
(15.27.59) cron2: if I might choose, I'd go for a "10-11" CET timeslot
(15.28.40) MaxF: 10 would conflict with my daily standup
(15.28.54) MaxF: but if that's better for everyone else, I think we can survive
if I miss it once per week
(15.29.18) cron2: 10:30-11:30?
(15.29.32) MaxF: works for me!
(15.29.49) dazo: +1
(15.29.52) mattock: that's pretty optimal for me as well
(15.30.14) ordex: +1
(15.30.45) plaisthos: 10:30 is okay for me
(15.31.23) rob0: that's awful for anyone in .US, but that should not matter
(15.31.49) cron2: rob0: you are in NL, no?
(15.31.55) dazo: I think you're the only one from US appearing here, rob0
(15.32.07) mattock: rob0: we had meetings alternating between "ok for europe,
ok for us" for a long time
(15.32.21) rob0: no, .us ^^ and I'm not complaining
(15.32.22) d12fk: how about later then?
(15.32.22) mattock: it was very rare for anyone from the US to join the "US
meetings"
(15.32.37) mattock: therefore we stopped trying to involve the US people :D
(15.32.44) cron2: "later" is increasingly congested for me (kids, US video
calls)
(15.32.53) plaisthos: and the US meeting was at 18 or 19 CEST, so often live
got into the way for us Europeans
(15.33.02) mattock: yep
(15.33.48) d12fk: I live in PST currently. need to set an alarm then ;-)
(15.33.49) mattock: anyhow, 10.30 seems to be ok
(15.33.49) cron2: I'd suggest moving to "Wednesday 10:30-11:30" then, and rob0
sends in things to discuss (which can be done today :) )?
(15.33.57) cron2: thanks :)
(15.34.33) rob0: sure, if I have anything I'd fuss at dazo :)
(15.34.42) dazo: *sigh*
(15.34.44) dazo: :-P
(15.35.18) mattock: next topic
(15.35.28) mattock: Yubikey and Google Titankey giveaway
(15.35.34) mattock: what is this about?
(15.35.41) cron2: selva wants one
(15.35.56) mattock: is somebody offering them?
(15.36.00) mattock: or is openvpn offering them?
(15.36.08) plaisthos: google/github are offering
(15.36.31) plaisthos: basically both are u2f keys but the yubikey can also do
X509/PKCS11 and GPG
(15.36.42) MaxF: this is a thing one can use for 2FA on github instead of a
phone app right?
(15.36.51) dazo: yeah
(15.36.58) plaisthos: MaxF: yes via U2F
(15.37.00) dazo: it's U2F
(15.37.05) ordex: well, not just for login, but I think also for signing
commits?
(15.37.17) ordex: or commits/git are unrelated?
(15.37.18) dazo: then you need PKCS#11
(15.37.20) plaisthos: ordex: not the titan key that is only U2F iirc
(15.37.23) ordex: ok
(15.37.38) ordex: the yubikey sounds good then - I'd get one if we decide to do
this
(15.37.39) plaisthos: the yubikey is a normal yubikey and you can put your gpg
or x509 keys on it
(15.37.45) ordex: ok
(15.38.02) dazo: I would prefer Yubikey 5 too, tbh
(15.38.13) mattock: I have a yubikey from 2-3 years ago which I have not
touched, I wonder if that's up-to-date enough...
(15.38.15) dazo: Much more versatile
(15.38.27) plaisthos: I have a yubikey but wouldn't mind having another newer
one for testing if we don't use all 5 slots %)
(15.38.45) plaisthos: mattock: depending on what you do and what revision it
might be just as well
(15.38.56) cron2: I'd like one too
(15.39.06) d12fk: me too
(15.39.20) d12fk: where do I need to apply for it?
(15.39.24) plaisthos: so selva, cron2, d12fk, ordex
(15.39.37) plaisthos: d12fk: I think one of us has to reply to the email and
request codes for them
(15.39.43) mattock: plaishos: ok, need to check it out, it's a shame its just
sitting in a box
(15.39.52) plaisthos: and those codes can then distribute to team members
(15.39.55) dazo: Lets see have an internal discussion with our management and
see if we can sponsor this to community developers
(15.40.11) plaisthos: d12fk: sponsor what?
(15.40.22) cron2: I like sponsoring :-) but isn't google sponsoring already?
(15.40.47) plaisthos: sponsering might be interesting if we end up with more
than 5 yubikeys we want
(15.41.16) plaisthos: then corp people can get them just reimbured via corp
while we can use the free codes with community developers
(15.41.52) mattock: +1
(15.41.58) dazo: cron2: Google gives the Titan, which has just U2F ... which is
only useful for web based auth ... if we put our PGP keys on this key, then git
signing gets hardened
(15.42.00) mattock: mine is a corp key
(15.42.23) dazo: yubikey has HOTP, U2F, PKCS#11 and a few more features
(15.42.51) dazo: via the Yubico Authenticator application you also get TOTP
(with the secret keys stored on the token)
(15.44.00) mattock: so free codes for community developers, buy stuff for corp
developers?
(15.44.05) plaisthos: I will write a reply saying that for us OpenVPN developer
the use of a singing card/pkcs11 makes the yubikeys more valuable and we would
therefore like to request 5 yubikeys
(15.44.40) plaisthos: and then give them to community developers who want them
and to corp devel if they need one too
(15.44.53) plaisthos: if we are short on codes/keys we just buy the extra ones
from corp
(15.45.22) cron2: *like*
(15.46.12) dazo: plaisthos: sounds good
(15.47.22) mattock: next topic?
(15.47.25) mattock: New default for MSSFIX in patch set
(15.49.22) plaisthos: just copyring form the topics:
(15.49.25) plaisthos: New default for MSSFIX in patch set
(15.49.25) plaisthos: current default is 1450, which translates to 1478 packets
for udp4 and 1498 for udp6
(15.49.28) plaisthos: proposal have a new default based on the outer size (mtu
as new option)
(15.49.31) plaisthos: Idea for new default: 1472 (1500 - one extra IPv4/UDP
header) or 1452 (1500 - one extra IPv6/UDP header) so we have good chance to
work if tunneled ourselves.
(15.49.34) plaisthos: Datapoint: Wireguard uses mtu 1420 as default, which
assumes that it can use 1500 on the outer packets with IPv6 and 1480 with IPv4.
(15.49.56) ordex: ovpn-dco does something similar
(15.50.08) cron2: read that, but I'm not sure why we want to change the default
mssfix setting
(15.50.21) plaisthos: cron2: why not?
(15.50.22) cron2: I have no specific opinion, just wanting to understand the
reasoning
(15.50.32) plaisthos: current default is 1450, which translates to 1478 packets
for udp4 and 1498 for udp6
(15.51.18) plaisthos: 2 byte for IPv6 is just weird and having ipv4 and ipv6
enacapsulation different might be also weird
(15.51.26) cron2: which is a bit high for UDP6 to pass 1492, so changing this
is not a bad idea
(15.51.53) cron2: so I'd go for "default max outer packet size = 1492"
(15.52.40) lev__: for ovpn-dco-win I had to set tun mtu to 1428 to accommodate
for the worst cast overhead
(15.53.23) plaisthos: lev__: this is currently just about the mssfix vlaue
(15.53.31) plaisthos: default mtu is much more complex and complicated
(15.54.10) lev__: crypto overhead 24, udp 8, ipv6 40
(15.55.09) plaisthos: setting mtu to something other than 1500 on just one side
unfortunately breaks things in different ways
(15.56.19) cron2: mtu is a different bag of worms
(15.56.25) cron2: let's fish mssfix first :-)
(15.58.18) plaisthos: okay I will add a patch my patchset that sets the new
default to be mssfix 1492 mtu
(16.04.29) mattock: meeting concluded I assume?
(16.04.45) cron2: I disappear into the next meeting...
(16.04.59) dazo: c ya'll
(16.05.37) mattock: ok see you
(16.05.55) mattock: I'll copy and paste this log into safety and wrap up the
summary tomorrow morning (no time now)
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
