Package: openvpn Version: 2.5.1-3 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.open...@sideload.33mail.com
The --proto option is documented to accept these args: udp tcp-client tcp-server The --remote option is documented to accept these args in the last position: udp / udp4 / udp6 tcp / tcp4 / tcp6 The --proto-force option is documented to accept these args: udp tcp What happens when you have: remote 198.19.34.56 443 # host 1 proto tcp-client remote 198.19.34.57 1194 udp4 # host 2 <connection> remote 198.19.34.58 1194 # host 3 http-proxy 192.168.0.8 8080 proto udp </connection> ? The proto parameter is documented to specify a default setting when a connection profile is used. But the above example has two profile-free connections. Users can (hopefully) assume that “tcp-client” will be internally modified to “tcp” when connecting to host 1. But what happens when host 2 is tried? In principle if proto is not merely specifying a /default/, then this is a conflict that should cause an error. The man page should state whether proto is: 1) a default (overridden by the remote setting); 2) an override (to replace the remote setting); or 3) a mutually weighted option that errors upon conflicts The option “--proto tcp” often appears in configuration files given to users by VPN suppliers. OpenVPN accepts it without error despite contradiction with the man page. So it seems the man page needs to clarify what that means. If openVPN is able to disambiguate *-client / *-server, then do those suffixes even serve a necessary purpose? W.r.t. connection profiles, the man page states that the “proto” option can be embedded in the grouping, and as a consequence when proto is specified /outside/ the grouping, it serves as a default /only/ if it comes before the profile. Is it safe to assume that sequence is irrelevant when it comes to interplay between profile-free connections and the proto setting? Another interesting example: proto-force tcp proto tcp-client remote 198.19.34.56 443 tcp4 remote 198.19.34.58 1194 udp The proto parameter gives no way to specify IPv4 or IPv6. So would the above indicate an option conflict, or does the tcp4 take precedence? Or is “tcp4” overridden by “tcp-client”? And which protocol is used on port 1194? And considering proto-force only has effect on connection profiles, is it simply ignored in this case? Users can perhaps experiment to work out which of the various possible behaviors result, but the man page should be written unambiguously. The man page mentions this bad URL: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html Naturally some users would try the InternetArchive version, which first redirects to: https://web.archive.org/web/20240114052848/http://sites.inka.de/sites/bigred/devel/tcp-tcp.html and then that redirects to a page telling users to visit a Github profile belonging to Barbarossa. From there, it’s unclear where to go. ** Docs in access-restricted walled gardens ** Many of the man page URLs link into an access-restricted walled garden. E.g. all openvpn.net links go to a Cloudflare site that is not open to all people. It’s an injustice for a Debian man page to refer users to exclusive resources that may exclude them. This is perhaps something that should be fixed in the Debian version as the upstream project has no duty to the users. Debian has a quality standard as well as a social contract and users to give equitable treatment to. Therefore IMO the Debian project should remove the access-restricted links from the man page and ideally replace them with openly accessible links. The most convenient way to do that would be to find mirrored versions of the pages in the Wayback Machine. This one-liner would perhaps do the job well enough: sed -e '/http.*.openvpn.net/s@https://\([[:alnum:].]*openvpn.net\)@https://web.archive.org/web/\1@' ietf.org has the same problem. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openvpn depends on: ii debconf [debconf-2.0] 1.5.77 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u5 ii liblz4-1 1.9.3-2 ii liblzo2-2 2.10-2 ii libpam0g 1.4.0-9+deb11u1 ii libpkcs11-helper1 1.27-1 ii libssl1.1 1.1.1n-0+deb11u3 ii libsystemd0 247.3-7+deb11u1 ii lsb-base 11.1.0 Versions of packages openvpn recommends: ii easy-rsa 3.0.8-1 Versions of packages openvpn suggests: ii openssl 1.1.1n-0+deb11u3 ii openvpn-systemd-resolved 1.3.0-3.1 pn resolvconf <none>
