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.

Hi,

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

Hi,

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

* Bernhard Schmidt [2024-03-18 08:58]:

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/

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.

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

* Bernhard Schmidt [2024-03-18 08:58]:

I might if the bug tracker were hosted in a more open and neutral
place. Microsoft venues are places I will not go. Github in particular
has access problems. Luckily Debian shelters users with a bug
reporting policy¹ that concurs:

  “Don't file bugs upstream

   If you file a bug in Debian, don't send a copy to the upstream
   software maintainers yourself, as it is possible that the bug
   exists only in Debian. If necessary, the maintainer of the package
   will forward the bug upstream.”

I wonder if the BTS could use improvement on this. Theoretically a
maintainer should be able to press a button that rounds up a time
range of bugs marked upstream and concatenate them into a periodic
digest for the upstream bug tracker.

① https://www.debian.org/Bugs/Reporting