Hi, On Sat, Jun 24, 2023 at 01:46:45AM +0200, Stella Ashburne wrote: > > Why would you want that, when bookworm ships with OpenVPN 2.6.2? > > I just checked and found that Debian Bookworm's version of OpenVPN > is 2.6.3-1. It is not yet updated to 2.6.4 (According to > https://github.com/OpenVPN/openvpn/blob/v2.6.4/Changes.rst, version > 2.6.4 provides some fixes to bugs discovered in 2.6.3)
I'm aware of that, I maintain that file :-) - for Linux users, there is
nothing really interesting in 2.6.3 -> 2.6.4. The bugs fixed in 2.6.4
affect Windows, MacOS/pkcs#11 and Android users.
There *is* a mem leak in 2.6.4 -> 2.6.5, and I assume that Debian is
picking up this bugfix and will do a fixed 2.6.3 re-release - by debian
policy, they will normally not upgrade to fully new versions within a
release, just pick relevant bugfixes and release updated packages.
> Secondly, I find that the pace with which the minor versions of 2.6 series
> is released to be too fast. It just takes about five months for 2.6.0 to
> reach 2.6.5.
This is an interesting statement - we intentionally tried to release
frequently, so bug fixes (that are inevitably found when doing a new
release with new features) can be distributed quickly.
So would you trust us more if we only did a 2.6.1 release after 5 months,
containing all the bugfixes found, instead of 5 release, each with just
a few commits?
> OpenVPN is a privacy-focused software and I fear there is
> insufficient time to uncover bugs and security vulnerabilities. I
> know there is this novel technology called DCO (data channel offload).
> Without enough time for it to prove itself that it is safe and
> secure for us to use, we end-users might unwittingly offload our
> sensitive data to the channels operated by state-sponsored hackers
> and cyber criminals. When this happens, DCO would become the butt
> of jokes among OpenVPN users.
Indeed, the DCO side of things has not seen as thorough testing and
scrutiny as the rest of the code.
On the other hand, there is no extra risk of offloading your data to
people that would not otherwise be able to see it - the kernel code (DCO)
can only handle encrypted data, so there is no way it could leak
unencrypted data. All the TLS handshaking is done by userland OpenVPN
just the same as in 2.5 (so, userland negotiates all the crypto, and
then informs the kernel "use this key") - if the kernel would not use
this key, the other end's OpenVPN would not be able to decrypto it.
If you have a root breach on your machine, yes, an attacker could read
packets handed to DCO - but that attacker could also read all your data
before going into OpenVPN, or modify OpenVPN to send a copy elsewhere
(= with or without DCO, after a root breach, you're toast).
> Let's compare the length of time taken to release 2.5.9 to that of version
> 2.6.5.
>
> Version 2.5.0 was released on 28 October 2020 and the final version
> 2.5.9 was released about two years and four months later. There was
> sufficient time for bugs and security vulnerabilities to be uncovered
> and patched.
This is one way to look at it, but I'm not sure how relevant it is -
2.5.x is in maintenance mode, with nothing really happning anymore,
except if we find a bug in "master", which is then fixed in 2.6.x and
2.5.x at the same time. So, for example, in 2.5.8 we still found a
NULL pointer bug, even though 2.5.0 was released two years ago - in
a dark corner of the code, which would not affect most users.
> Thirdly, most commercial VPN service providers might not be keen
> to upgrade their OpenVPN versions to the 2.6 series due to stability
> concerns and the impact of the latter on their businesses.
"most commercial VPN service providers" just suck big time at code
maintenance, and talking to OpenVPN upstream - they hack extra features
into OpenVPN, sometimes breaking the protocol in incompatible ways, and
most of them never nother to actually speak to us to ensure best results
for their customers... and then we get to deal with the bug reports.
This said, commercial OpenVPN providers would do very good in looking
at 2.6.x, as the increased efficiency of using DCO means "much less CPU
needed, less energy spent, money saved".
But this is really not a relevant argument for the question "why do you
want a 2.5.9 package for debian 12" - what commercial VPN providers do
is their choice, and we've taken great care to ensure OpenVPN compatibility
- meaning, if you run 2.6.x, and the other end runs OpenVPN 2.4 or 2.5,
it will still interoperate just fine (we do test with 2.2 and 2.3 as
well, but these will need --compat-mode settings on 2.6).
But all this said - providing packages for Debian 12 needs resources on
the side of the OpenVPN project (read: Frank needs to do that). Since we
think 2.6.x is better than 2.5.x, and Debian thinks that 2.6.x is stable
enough to include into bookworm, we think this is human life time better
spent elsewhere. Like, on improving OpenVPN.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
