Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens
* Bernhard Schmidt [2024-03-18 08:58]: > > For this, while I share your concerns about the unmindful use of Cloudflare > reverse proxy for basically everything I don't agree to call this a "walled > garden". Cloudflare is a walled garden: https://thefreeworld.noblogs.org/post/2024/03/18/cloudflare-has-created-the-largest-most-rigidly-exclusive-walled-garden-in-the-world/ It’s also the most severely disempowering walled garden, worse than Facebook and Google: https://thefreeworld.noblogs.org/post/2024/03/20/comparison-of-the-human-disempowerment-severity-of-3-walled-gardens-facebook-google-and-cloudflare/ > Certainly not enough to call the mentioning of an URL that just > _now_ happens to be "protected" by Cloudflare a policy violation (or > social contract violation) and alter the URLs to web.archive.org, > which to my experience is broken quite often, dog-slow and not > necessarily up-to-date. I think this would be more of a disservice. The Social Contract (DSC) and the Debian Free Software Guidelines (DFSG) are concerned with equality (“No Discrimination Against Persons or Groups”) and quality (DSC ¶4). One might say that wholly denying access to some people in order to give other people in more privileged groups access that loads faster and is more up to date is better quality, but it could also be argued that forcing some people into oppressive venues and denying others is bad quality overall. To be clear, I should make the caveat that the DSC and DFSG are essentially meaningless. There’s no enforcement procedure and they aren’t really written well to fully convey the author’s intent. They are just spiritual guidance at best. But I brought it up because they do convey the philosphy of not excluding people arbitrarily. > Most of the interesting content should be in the manpage and in > /usr/share/doc/packages/openvpn anyway. > > If you have concerns about the use of Cloudflare, please raise this > upstream. I know there are some devs sensitive to these concerns listening. The Debian policy manual¹ encourages bulky documentation to be packaged in a separate $package-doc package. That’s not a task for upstream devs. That’s really the best quality because it gives some degree of immunity to bad links and walled gardens (depending on how well it’s done). It is optional, of course, but IMO it’s the best solution when the external docs are in an exclusive walled garden particularly when the man pages refer users into that walled garden. ① https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation
Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens
Hi, 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. For this, while I share your concerns about the unmindful use of Cloudflare reverse proxy for basically everything I don't agree to call this a "walled garden". Certainly not enough to call the mentioning of an URL that just _now_ happens to be "protected" by Cloudflare a policy violation (or social contract violation) and alter the URLs to web.archive.org, which to my experience is broken quite often, dog-slow and not necessarily up-to-date. I think this would be more of a disservice. Most of the interesting content should be in the manpage and in /usr/share/doc/packages/openvpn anyway. If you have concerns about the use of Cloudflare, please raise this upstream. I know there are some devs sensitive to these concerns listening. Bernhard
Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens
Control: tags -1 upstream Hi, Users can perhaps experiment to work out which of the various possible behaviors result, but the man page should be written unambiguously. I completely agree, but this is not something the Debian OpenVPN maintainers can do. Please check the latest version at the upstream Github repository https://github.com/OpenVPN/openvpn and file issues there, if the issue is still present. Bernhard
Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens
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 remote 198.19.34.58 1194# host 3 http-proxy 192.168.0.8 8080 proto udp ? 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 libsystemd0247.3-7+deb11u1 ii lsb-base 11.1.0 Versions of packages openvpn recommends: ii easy-rsa 3.0.8-1 Versions of
