Devil's advocate: Is this something one runs often enough that it needs to be in PATH, and what are the risks to having it there?

Your question makes no sense and is not relevant here, the number of times an application is run has no bearing on where it belongs per the FHS. As far as risks that also makes no sense either unless you have something specific in mind as an issue. You may consider looking at other packages as to where executable scripts and binaries are placed for more clarity, or speak with other package maintainers as to best practices.

Then I'll restate it so that it might make more sense, as it is relevant.

The script is designed to have all it's components and config files in with it in the cwd. By default, the cwd is also the PKI dir. It's well suited to use from a git checkout or extracted tarball, but not designed with packaged distribution or the FHS in mind. Given this, when it was initially packaged, the best practice of following upstream as closely as possible took precedence over adhering to the FHS.

The only way to make this software work with proper FHS layouts would be to place the script where it is, the configs and x509-types in /etc, and create a wrapper script, living in /usr/bin, to call the script with the parameters needed to make that work. This seems potentially brittle, and adds another layer of abstraction to troubleshooting.

If anything, since the data this software creates is by default written to it's own cwd, perhaps the whole lot should move to /etc. Thoughts?

My thoughts:
1 - using /etc is even more wrong that what you were doing before
2 - there is a lack of knowledge or willingness to actually create and submit a patch upstream to fix this (making a patch was noted in the original issue)
3 - a possible major misunderstanding of the Linux file system, Fedora packaging guidelines, and packaging best practices

I am not sure if you looked at the actual script but there are only a couple variables that need changed for this to work. I have no idea why or how you arrived at making a wrapper script as that is beyond unnecessary.
That being said, below is a patch that seemed to work for me in a test setting, but I didn't test every possible option or combination of options.

--- easyrsa.orig        2019-08-28 15:10:42.191974000 -0500
+++ easyrsa     2019-08-28 15:15:54.797974000 -0500
@@ -1557,7 +1557,7 @@
        # Set defaults, preferring existing env-vars if present
        set_var EASYRSA         "$prog_dir"
        set_var EASYRSA_OPENSSL openssl
-       set_var EASYRSA_PKI     "$PWD/pki"
+       set_var EASYRSA_PKI     "/etc/easyrsa/pki"
        set_var EASYRSA_DN      cn_only
        set_var EASYRSA_REQ_COUNTRY     "US"
        set_var EASYRSA_REQ_PROVINCE    "California"
@@ -1578,12 +1578,12 @@
        set_var EASYRSA_TEMP_DIR        "$EASYRSA_PKI"
        set_var EASYRSA_REQ_CN          ChangeMe
        set_var EASYRSA_DIGEST          sha256
-       set_var EASYRSA_SSL_CONF        "$EASYRSA_PKI/openssl-easyrsa.cnf"
-       set_var EASYRSA_SAFE_CONF       "$EASYRSA_PKI/safessl-easyrsa.cnf"
+       set_var EASYRSA_SSL_CONF        "/etc/easyrsa/openssl-easyrsa.cnf"
+       set_var EASYRSA_SAFE_CONF       "/etc/easyrsa/safessl-easyrsa.cnf"

        # Same as above for the x509-types extensions dir
-       if [ -d "$EASYRSA_PKI/x509-types" ]; then
-               set_var EASYRSA_EXT_DIR         "$EASYRSA_PKI/x509-types"
+       if [ -d "/etc/easyrsa/x509-types" ]; then
+               set_var EASYRSA_EXT_DIR         "/etc/easyrsa/x509-types"
        else
                #TODO: This should be removed.  Not really suitable for packaging.
                set_var EASYRSA_EXT_DIR         "$EASYRSA/x509-types"

1. Filesystem placement for software like this isn't as straightforward as "correct" or "wrong".

2. I'm not sure on what basis you're assessing my knowledge. I *can* create a patch to send upstream, but it's not my place to attempt to make upstream shoehorn their project into our specific use case. That's for our packaging.  If there's a bug or change that would universally benefit users of this software, I would absolutely send a patch upstream. I do so regularly for other projects.

3. I'm certainly fallible, but I've been packaging for Fedora ans supporting *nix generally for long enough that I'd like to think I have at least a working knowledge of filesystem layout and packaging best practices. I'm absolutely familiar with the Packaging Guidelines.

I'll consider applying a more sustainable version of your changes; there are cases where /etc is not simply in /etc.


In the future, I would suggest taking a less confrontational tone with those whose assistance you're seeking. I'm a patient woman, and open to and even eager for constructive criticism, but like most people, I'd like to think I've earned a presumption of at least semi-competence.

As an upstream OpenVPN maintainer who also knows a bit of the easy-rsa history, I agree with Gwyn.

Easy-rsa is not a conventional utility expected to be in $PATH, by design.  Using /etc for easy-rsa managed files is also wrong, because a CA isn't a local host configuration.  Easy-rsa is not even meant to be installed at the same host as it is issuing certificates for.  Ideally the easy-rsa files should be on an offline storage medium, only to be activated when a new certificate needs to be issued - and if not, it should not be used on a host accessible directly via the Internet.

A service running on a server should only need the CA certificate, DH parameters, server key and server certificate, and that's all.  This is all a server needs.  If using certificate based client authentication, the client only needs the CA certificate, client key and client certificate.  That's all.  The rest (and in particular the CA private key) should be very well protected; if any of these files (and in particular the CA private key) leaks out of your control, you can no longer trust this CA.

I suggest just closing this ticket as WONTFIX.

I concur.