[Pkg-utopia-maintainers] Bug#1001073: Bug#1001073: network-manager-openvpn: [bullseye] importing ovpn file using GUI results in non-functional VPN (fails due to auth timeout)

Fri Dec 3 19:39:30 GMT 2021

Control: tags -1 bullseye upstream fixed-upstream

Michael Biebl <biebl at debian.org> 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 <sgala at redhat.com>
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.

    [bgalvani at redhat.com: 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 <bgalvani at redhat.com>
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 <thaller at redhat.com>
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 <thaller at redhat.com>
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 <bgalvani at redhat.com>
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 <bgalvani at redhat.com>
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 <ernestas at baltic.engineering>
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 <katelyn.schiesser at gmail.com>
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 <thaller at redhat.com>
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 <katelyn.schiesser at gmail.com>
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 <ralph.ruijs at ing.com>
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 <florian at apolloner.eu>

    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 <katelyn.schiesser at gmail.com>
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 <bgalvani at redhat.com>
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 <alex at forrow.com>
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 <thaller at redhat.com>
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 <thaller at redhat.com>
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 <emmanuel at gnome.org>
Date:   Mon Mar 30 08:34:20 2020 +0200

    editor: add push-peer-info support

  commit e6a415cd5773f3206979f8fc24a669c47a0478f9
  Author: Emmanuel Pacaud <emmanuel at gnome.org>
  Date:   Mon Mar 30 08:33:19 2020 +0200

      import-export: add push-peer-info support

  commit cb2134fd4172ae7afda7133710a7ee596e243e85
  Author: Emmanuel Pacaud <emmanuel at gnome.org>
  Date:   Mon Mar 30 08:29:57 2020 +0200

      service: add support for push-peer-info

  commit 5b038a581f8c4d529d25be6c0af55e115d2536d2
  Author: Emmanuel Pacaud <emmanuel at gnome.org>
  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 857 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20211203/bf3c0e88/attachment-0001.sig>