Control: tags -1 bullseye upstream fixed-upstream Michael Biebl <[email protected]> writes: > On 03.12.21 19:07, Nicholas D Steeves wrote: > [snip] >> The fix for bullseye should cherry-picked from upstream VCS to make >> this package usable on Debian stable, because "The Debian Desktop >> doesn't work with commercial VPNs" harms Debian's reputation IMHO. > > Right. Could you run a git bisect to find the commit which we need to > cherry-pick= > Uploading a new upstream release 1.8.16 is probably not something the > stable release managers will ack but a targetted fix is more likely to > be accepted. >
Of course, that's why I suggested cherry-picking ;-) Looking at the commit history, bisecting will be a waste of time, because d1942fd from 1.8.16's HEAD^10 (very recent recent) is required for bullseye's OpenVPN 2.5.x...honestly, without ovpn 2.5.x support, this package looks RC buggy for bullseye and maybe it just doesn't have many users? Ie: Maybe most of its more technical users are tracking sid? My experience is that all less technical users who use a commercial VPN use the proprietary application furnished by the provider when they can't get our (and derivatives) network-manager-openvpn to work properly. Since 1.8.12, there are 20 relevant commits: 2 security related, 1 definitely needed, 1 needed for at least one well-known commercial VPN provider, 1 likely needed, 1 nice to have, 1 for being a good netizen, and the rest I either don't know how to test, or don't have the OpenVPN knowledge to assess. I've added my annotations with the following pattern "** ". commit ab8ad62f0865d98210265327d8274a55c58e8db5 Author: Santiago Gala <[email protected]> Date: Fri Sep 24 19:57:48 2021 +0200 helper: set the can-persist flag OpenVPN is able to persist the connection across link changes and outages. Set the can-persist flag in the configuration returned to NetworkManager. [[email protected]: rewrote commit message] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/40 ** this one solves several outstanding bugs in the BTS. I think we want this one, because users have been asking for it for years, and because if a laptop loses an unreliable wifi link, the VPN will disconnect, and then won't reconnect when the link is restored. I think the security team would support this one. commit f9286da94dbfa1d585f0dc8d2f57640d467e2193 Author: Beniamino Galvani <[email protected]> Date: Thu Jun 3 18:19:39 2021 +0200 helper: fix parsing of IPv6 configuration If the server pushes, for example: ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1 NetworkManager considers the first argument as the subnet and the second as the peer, and so it does something equivalent to: ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1 which appears in the "ip -6 addr" output as: inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global valid_lft forever preferred_lft forever Instead, according to 'man openvpn', NM should simply add address 2001:db8:f00:bebe::1003/64 and use the second argument as a fallback gateway for the routes specified by '--route-ipv6' ** solves other bugs reported in the BTS commit 3c47520e999d5301eec69838e11ad4053bef4f20 Author: Thomas Haller <[email protected]> Date: Mon Jun 7 19:00:45 2021 +0200 service: assume that we run openvpn 2.4 or newer by default Our version detection might fail or give the wrong result. So change the code to assume (in case of unknown version) that we run version 2.4 or newer. By now, that should be the common case and we should only assume to run 2.3 or older if we successfully detected it. ** the absence of this one might cause my bug, but I suspect this one isn't needed, because if it was someone would have filed a grave bug against network-manager-openvpn. Sorry, I'm not sure. commit d1942fdc94786ea412aadda2bec8f6b9b9005c85 Author: Thomas Haller <[email protected]> Date: Mon Jun 7 18:47:56 2021 +0200 service: fix detection of openvpn version Since 2.5.0, `openvpn --version` no longer exits with code 1. That broke the version detection. https://github.com/OpenVPN/openvpn/commit/96ae327add16f06ac8bc28cfbf9ba0abfcc7129c ** This one must be backported commit 353a521bc08e2c762e7c63d10f8e3233e9442b08 Author: Beniamino Galvani <[email protected]> Date: Fri Feb 19 10:03:41 2021 +0100 helper: ignore IPv4 configuration without an address This is the same as commit 56bb08f2956e ("helper: ignore IPv6 configuration without an address") but for IPv4. NetworkManager always rejects configurations without an address, so ignore them. A configuration without address can be created, for example, if the server advertises IPv4 routes or domains without an address. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/35 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/62 ** I'm not sure if this one is needed. Can this information be gathered by introspecting a working connection or from logs? commit 56bb08f2956e7e394b017344541e1b7ddf46f2b1 Author: Beniamino Galvani <[email protected]> Date: Wed Feb 10 12:01:37 2021 +0100 helper: ignore IPv6 configuration without an address OpenVPN 2.5.0 started to pass incomplete IPv6 configurations when the server is not fully configured for IPv6 but has some IPv6 directives. For example, it is enough to add 'push "route-ipv6 ::/0"' to a IPv4-only setup to trigger this behavior. As a result, NetworkManager rejects the configuration as invalid and the connection fails. Fix this by ignoring IPv6 configurations without an address. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64 ** I'm not sure what method my commercial ipv6 service uses to block ipv6, but this commit is possibly related. eg: if it pushes some kind of /dev/null ipv6 route. commit 717a1d41be0b039778b4eb85bca57f9356bb87aa (upstream-vcs/wip/ernestask/tls-crypt-v2-client) Author: Ernestas Kulik <[email protected]> Date: Mon Jan 11 17:30:13 2021 +0200 Handle tls-crypt-v2 keys OpenVPN 2.5.0 adds client-specific tls-crypt keys under the tls-crypt-v2 option, which is currently not supported. This commit adds the necessary import/export machinery to support it. ** I'm not sure if this is relevant to my bug or not... I use "tls-client" and "remote-cert-tls server". commit 34a0c9257aac9ed6e3ac7cdad6f6cc7d8107eef1 Author: Katelyn Schiesser <[email protected]> Date: Wed Jul 8 11:32:32 2020 -0700 Handle the various pkcs12/cert/key/ca combinations. OpenVPN allows supplying PKCS#12 client cert/key *or* PEM client cert/key, as well as a PEM CA cert in either case. When supplying --pkcs12, the args --cert and --key can not be used. So, you can have one of the following: - PKCS#12 combined cert/key/ca (one file): --pkcs12 - PKCS#12 combined cert/key/ca with PEM CA: --pkcs12, --ca - PEM cert/key, PEM CA: --cert, --key, --ca If a user tries to import an invalid config, they will be met with the appropriate error message. The editor dialog also enforces the PKCS#12/PEM restrictions. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/29 ** not relevant to my bug, but nice to have. commit ba6c4bf1b827a1164032e0bf3cef0a72b79b66ae Author: Thomas Haller <[email protected]> Date: Fri Oct 23 15:21:57 2020 +0200 properties: fix string comparison in hash_copy_advanced() wrongly using NM_IN_SET() CC properties/libnm_vpn_plugin_openvpn_editor_la-nm-openvpn-editor.lo properties/nm-openvpn-editor.c:2508:6: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare] if (NM_IN_SET (key, NM_OPENVPN_KEY_HTTP_PROXY_PASSWORD)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./shared/nm-utils/nm-macros-internal.h:531:45: note: expanded from macro 'NM_IN_SET' #define NM_IN_SET(x, ...) _NM_IN_SET(||, typeof (x), x, __VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./shared/nm-utils/nm-macros-internal.h:526:45: note: expanded from macro '_NM_IN_SET' #define _NM_IN_SET(op, type, x, ...) _NM_IN_SET_EVAL_N(op, type, x, NM_NARG (__VA_ARGS__), __VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./shared/nm-utils/nm-macros-internal.h:523:11: note: expanded from macro '_NM_IN_SET_EVAL_N' !!_NM_IN_SET_EVAL_N2(op, _x, n, __VA_ARGS__); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./shared/nm-utils/nm-macros-internal.h:515:50: note: expanded from macro '_NM_IN_SET_EVAL_N2' #define _NM_IN_SET_EVAL_N2(op, _x, n, ...) (_NM_IN_SET_EVAL_##n(op, _x, __VA_ARGS__)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <scratch space>:54:1: note: expanded from here _NM_IN_SET_EVAL_1 ^ ./shared/nm-utils/nm-macros-internal.h:498:53: note: expanded from macro '_NM_IN_SET_EVAL_1' #define _NM_IN_SET_EVAL_1( op, _x, y) (_x == (y)) ^ ~~~ ** wow...don't you love commit messages like this? I have no clue if this is needed or not. commit 667113138d3e27cb367e87090955e50885913407 Author: Katelyn Schiesser <[email protected]> Date: Sat Oct 17 23:30:54 2020 -0700 Accept all valid 'proto' arguments. OpenVPN allows for a bunch of different args for 'proto', namely 'udp' and 'tcp' variants that include '4' or '6', and specific to tcp, '-client' suffixes. This was already defined in shared/util.h; this commit changes the 'proto' check to also use the 'NMOVPN_PROTCOL_TYPES' array, and adds test for all supported protos. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/59 https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/30 ** This one is likely needed! commit e83b4f89962854f75475ef0fe86f938746c684db Author: Ralph Benjamin Ruijs <[email protected]> Date: Mon Jul 13 22:23:09 2020 +0200 Added option for allow-pull-fqdn This allows the server to push routes that include DNS-names and not just ips/networks. OpenVPN will then resolve those names and add the routes accordingly. As an example `push route google.com` will result in all traffic to google.com be redirected over the vpn. The `up` scripts do not need any special handling as they are passed the resolved options: route_network_13=ip_1_of_google route_network_12=ip_2_of_google Co-authored-by: Florian Apolloner <[email protected]> https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/28 ** I think it's likely commercial VPNs are using this. How can I test? commit 483a04288b2b79e523901c85fba8b82379a323d2 Author: Katelyn Schiesser <[email protected]> Date: Tue Jul 7 21:17:21 2020 -0700 Add --explicit-exit-notify by default when --proto udp When using UDP, there is no transport-protocol method to notify the server that the client has disconnected. For TCP, the socket closing signals the server to close the peer instance; for UDP, the server must wait for a configured --ping-exit, --keepalive, or similar to free up the connection. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/24 ** this one seems like a protocol correctness thing that one can't be a good netizens without. Ie: not needed for technical reasons per se, but for social/reputation ones. commit 29d1e5d7dd730cd9fb985ee559b51db0009824ce Merge: 93cec82 13080f3 Author: Beniamino Galvani <[email protected]> Date: Tue Jul 7 10:02:56 2020 +0200 merge: branch 'alexforrow/NetworkManager-openvpn-master' Add remote-random-hostname support. https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/23 [pasted from MR: –remote-random-hostname Prepend a random string (6 bytes, 12 hex characters) to hostname to prevent DNS caching. For example, “foo.bar.gov” would be modified to "<random-chars>.foo.bar.gov". This change adds an option to the UI, import/export and the appropriate flag to the OpenVPN executable.] ** this sounds like it potentially closes a CVE commit 64c9877db25b2f3c3f77e64693dfb25229917cbf Author: Alex Forrow <[email protected]> Date: Wed May 27 23:16:08 2020 +0100 support for remote-random-hostname parameter ** I know of at least one popular commercial VPN service that uses this commit 67d9ebb4f2b58287162284619168224afc04d9e0 Author: Thomas Haller <[email protected]> Date: Thu Apr 23 09:47:26 2020 +0200 helper: cleanup parsing foreign_option_* environment variables There is no need to restrict parsing to 256 variables. Just continue iterating until we find a variable that is missing. Also, don't use magical numbers - tmp += 12; /* strlen ("dhcp-option ") */ + tmp += NM_STRLEN ("dhcp-option "); ** seems relevant, but sorry, I don't know if it's needed commit c4ad1b66f090e5a2ae782d7d7067a658587909bd Merge: 5b038a5 faa15cd Author: Thomas Haller <[email protected]> Date: Mon Mar 30 10:02:44 2020 +0200 merge branch 'EmmanuelP:wip/push-peer-info' https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/20 commit faa15cde7193aecbe955df143cdb7f09be1e56aa Author: Emmanuel Pacaud <[email protected]> Date: Mon Mar 30 08:34:20 2020 +0200 editor: add push-peer-info support commit e6a415cd5773f3206979f8fc24a669c47a0478f9 Author: Emmanuel Pacaud <[email protected]> Date: Mon Mar 30 08:33:19 2020 +0200 import-export: add push-peer-info support commit cb2134fd4172ae7afda7133710a7ee596e243e85 Author: Emmanuel Pacaud <[email protected]> Date: Mon Mar 30 08:29:57 2020 +0200 service: add support for push-peer-info commit 5b038a581f8c4d529d25be6c0af55e115d2536d2 Author: Emmanuel Pacaud <[email protected]> Date: Mon Mar 30 08:57:50 2020 +0200 import-export: fix coding style of compress test https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/21 ** Possibly needed to prevent merge conflict with Pacaud's later work. ** Sorry, I don't know OpenVPN well enough to be able to say if this is needed. How can I test? The remaining commits since 1.8.12 are eiher not relevant, or are translation-related. Regards, Nicholas
signature.asc
Description: PGP signature
